«Тяжёлый» прикладной софт: будни разработки и внедрения
Расскажу про особенности «тяжелого» коммерческого прикладного софта для крупных компаний и приведу пару примеров из России.
В большом бизнесе просто нет таких ситуаций, когда можно купить лицензию и сразу сесть пользоваться. Нужно аккуратно дорабатывать напильником, причём часто так, что иногда написать с нуля занимает столько же времени.— Софт никогда не бывает 100% готовым, потому что постоянно в бизнесе происходят изменения.— Софт никогда не останавливается в модификациях.— Софт нужно постоянно поддерживать.
Заходите, покажу ад перфекциониста.
Цель внедренияГлавная задача любого корпоративного ПО — автоматизация чего-то, что раньше не делалось или делалось руками. То есть, переводя на человеческий язык — либо экономия (чаще всего), либо получение нового функционала для более успешного решения задач.Вот, например, каждый раз, когда ваш ребёнок естмедведя Барни, или вы жуёте Дирол, или подростки не находят фольгу в открытом Alpen Gold, происходит много сложных процессов. Покупкой вы косвенно запускаете множество транзакций в ERP, логистике и других IT-подсистемах розницы и производителя. Всё это так или иначе отправляется в дата-центры, где обсчитывается. Самая важная задача — своевременные точные поставки, так, чтобы логистика правильно отрабатывала. При этом грамотно написанный софт экономит миллионы долларов на оптимизации складов, улучшении расписания автотранспорта (уменьшении количества нужных машин), точности предсказания спроса и, соответственно, меньшего брака по сроку годности. Например, здесь с медведями и остальным заказчик экономит несколько миллионов рублей в год. Или вот пример моего коллеги про перепись, где удалось сэкономить и на оборудовании и на людях (а там, на секундочку, полмиллиона человек ходят по стране).
То есть цель автоматизации в настоящий момент практически всегда — экономия (в перспективе). На втором месте, по моим ощущениям, по важности мотивации развивать IT-инфраструктуру — больше контроля и прозрачности. К примеру, те же системы документооборота и BPM вводят для улучшения контроля. Вот ещё ситуация, где компания легко могла потерять вагон стали просто из-за особенностей учёта.
Бывают и чисто технические цели — автоматизация изменений в IT-подсистемах (чтобы не дёргать IT-отдел каждый раз, когда коммерческому директору нужно что-то поменять), контроль изменений кода, слежение за всеми активами (лицензиями, серверами и т.п.), мониторинги и прочие вещи. Пример решений многоходовой автоматизации IT-работ — вот.
Естественно, универсальных решений не бывает, равно как не бывает двух одинаковых компаний. Весь софт, все программно-аппаратные комплексы и другие решения — всё это делается конкретно под заказчика.
Лирическое отступление про российскую разработку Пока мы не ушли дальше, стоит остановиться на важном вопросе доработок и допиливания лобзиком. В крупном бизнесе главное слово — кастомизация. Нужно писать под процесс, с чётким пониманием кто будет работать, какие точно задачи решать и так, чтобы было удобно. Иначе софт автоматизации становится не помощью в работе и средством экономии, а костылём, или, хуже — помехой, мешающей нормально работать. Отсюда — либо очень, очень серьёзное допиливание коробочных версий вместе с вендорами, либо разработка на базе какого-то фреймворка (примеры ниже), либо вообще с нуля.Соответственно, в первых двух случаях сложный вопрос (особенно в условиях нынешней экономической обстановки) является ли разработка российской. Нет, понятно, что компьютеры придумали не в России, булеву логику тоже, русских ОС тоже не особо видно –, но чёткий критерий всё же нужен. В Минкомсвязи ещё в ноябре предложили свое видение понятия «российская разработка». Это некий софт, правообладателем которого является российская компания, и отчисление иностранным компаниям за использование их модулей не превышает 30%. В целом, вполне демократично и удобно для рынка — речь как раз о хорошей кастомизации.
Но давайте уже покажу примеры наших разработок.
Медкиоск Начнём с достаточно простой вещи: устройства, состоящего из известного набора «деталей конструктора» с относительно простым ПО. Это ПАК, который выглядит примерно как банкомат, позволяющий менее чем за 3 минуты проводить диагностику основных показателей состояния организма человека. Ставится в помещениях.В базовой комплектации умеет: — Взвешивать пользователя, — Измерять давление, пульс и насыщенность крови кислородом, — Проверять температуру тела, — Нюхать дыхание и сообщать про алкоголь в нём, — Авторизовывать сотрудника по смарткарте (например, от системы контроля доступа в помещение) или отпечатку пальца (в ближайшем будущем будет реализована возможность авторизации по радужной оболочке глаза), — Снимать видео самого обследования и передавать его на сервер, — Хранить данные в базе и отдавать их в другие подсистемы компании, — Проводить аналитику на основе текущих замеров и предыдущих обследований.
Разумеется, к нему можно поставить и дополнительные модули, например, снимать одно отведение ЭКГ или проверять сопротивление кожи (грубо говоря, уровень стресса).
Назначение у него предельно простое — проверять сотрудников перед сменой. Например, упрощать предполётный медосмотр, фиксировать состояние оператора АЭС, ставить в МВД, на буровую установку на шельфе или в тайге, и так далее. На тестах мы поставили его прямо около нашей столовой — выстроилась целая очередь желающих проверить себя. Многим очень понравилось регулярно следить за базовыми показателями.
Это сборка из аппаратной платформы, написание интегрирующего софта или накатка готового решения от западных коллег с такими же киосками, плюс связка с базой данных компании.
Росавтодор — поддержка госуслуг Теперь возьмём что-нибудь «потяжелее», например, работу с потоком данных госкомпании. Для государственных предприятий есть нормативные документы, определяющие перечень услуг, которые нужно оказывать в электронном виде. В 2012 и 2014 годах мы выигрывали конкурсы Росавтодора на реализацию таких задач. Если коротко — ситуация там в следующем: раньше нужно было делать выписки из единого реестра автомобильных дорог ЕГРАД, и принимать обращения граждан. Второе потом выбыло из списка госуслуг, я подозреваю — потому что это была одна из немногих форм, куда можно было написать в духе: «Я езжу по этой дороге с 87 года и за это время она ни разу не ремонтировалась». Писали по всем поводам, а по правилам, госорган обязан рассмотреть любую заявку и перенаправить её в правильное ведомство.Что же касается запросов по выпискам, то архитектура такая: запросы поступают на единый портал межведомственного электронного взаимодействия, а затем идут в Росавтодор в формализованном виде. Мы принимаем и парсим, кладём в систему электронного документооборота на стороне Росавтодора, дальше пересылаем задачу в электронный реестр автомобильных дорог и обрабатываем в нем, в том числе получая от Государственной информационной системы о государственных и муниципальных платежах информацию об оплате услуги. Приняли решение — оно в обратном порядке идет на портал госуслуг через коннектор. По ходу движения — подписывается ЭЦП, попадает в личный кабинет заявителя.
Форма заявки на выписку из ЕГРАД
По самому реестру автомобильных дорог — у нас в стране более 160 тысяч разных организаций-владельцев дорог. Распоряжение обязывает предоставлять все сведения — о состоянии, протяженности, владельцах и пр. — по автомобильным дорогам. Раньше эти сведения предоставлялись в бумажном виде –, а в реестр их вносили сотрудники агентства. Сейчас этим занимается сам владелец дороги, поэтому у заказчика высвободились ресурсы, которым больше не нужно разбирать по номеру дома рядом с объектом, что это за дорога и откуда, да и риск ошибки снизился — каждая инфокарта теперь подписывается ЭЦП, и только после этого автоматом попадает в реестр.
Мы с этим работаем с 2003 с года, и предметная область хорошо знакома. Заказчик ценит.
Из сложностей на таких проектах — рассинхронизация действий ведомств: например, Минкомсвязи отвечает за форму на сайте, а мы — за коннектор. Чтобы уложиться в регламентированные сроки, часто нужно делать очень много вещей заранее, и здесь понимание предметной области очень важно. Разумеется, заказчик говорит на своем языке — нужно постоянно переводить на язык спецификаций и с него обратно. После каждой встречи — протокол, до чего договорились в функциональной части и что это значит.
Самая важная часть разработки — убедиться, что мы с заказчиком друг друга правильно понимаем. Поэтому мы используем свой фреймворк для документооборота, где есть возможность «на лету» собирать страшные, но работающие прототипы. Правильный GUI натягивается поверх абстракций потом, главное — чтобы заказчик видел, что если нажать то-то, то заявка в таком-то виде пойдёт в документооборот. Такая страховка по макетам отчётных форм очень нравится не только коллегам из Росавтодора.
Но не надо думать, что UI — последнее дело. Конечные пользователи системы — не IT-специалисты, и для них нужно очень много и сильно адаптировать всё. В логике разработчика нужно делать атрибутивные формы, описывающие все параметры запроса. В логике пользователя — нужны простые интерфейсы, где элементы группируются не по удобству разработчика, а по удобству сотрудника. Чтобы в одной группе были контролы, относящиеся к одному объекту тематики, процесс был простой и понятный. Мы много чего попробовали — даже обучение не даёт большого результата. Поэтому специально делаются упрощенные интерфейсы (для нас это допработа) — это сильно упрощает внедрение.
По моей практике, если так с прототипами и GUI не делать, решение с высокой вероятностью пойдет в мусорку. Получится продукт, который формально отвечает требованиям, но не подходит для каждодневного использования. Наверное, поэтому мы так долго на проекте. Другие контрагенты часто меняются, к нам новые люди часто присматриваются с подозрением. Потом видят, что мы реально делаем, смотрят на результаты, приходит понимание.
TaskList Integrator А есть другой класс задач, рассчитанный на то, чтобы автоматизировать автоматизацию, или же упростить взаимодействие пользователей с IT-подсистемами компании. Например, в последние годы стала появляться ещё одна задача интеграции подсистем. Вот наше собственное решение, которое, в частности, используется внутри КРОК.Ситуация такая — у заказчика (да и у нас) часто стоит большой зоопарк IT-подсистем. Задачи сотруднику могут приходить из разных источников. Например, в системе документооборота пришёл новый приказ, в BPM нужно переходить к следующей стадии проекта, в трекере начальник поставил новую задачу, в CRM срочно нужно сделать что-то ещё, плюс проснулась кадровая подсистема и напоминалка про регулярные технические работы. Ад.
Всё это удобно и просто сводится в одну систему типа почты-трекера.
Вход через коннекторы для взаимодействия с другими системами, выход — через такие же коннекторы для обновления данных снаружи. Внёс правки в TLI — получил правки в системе, даже заходить в неё не надо. «Под капотом» Tomcat, PostgreSQL и CentOS/RedHat, JAVA.
На планшетах есть оффлайн-режим и постоянная синхронизация, очень удобно для путешествующих топ-менеджеров и инженеров. В одной госкорпорации, к примеру, это решение плюс специальная защита — планшеты руководителей (x509, ГОСТ, вход по смарткарте, VPN, ЭЦП, джейлбрейк-вайп). Есть iOS, Win и Android-приклад.
Проект молодой, всего 2 года. Причина появления такого продукта в том, что нередко Enterprise-софт пишется либо недостаточно «красиво», либо неудобно. Про UI/UX думают так — чего тут думать, тут трясти надо. Поэтому если кто-то столкнулся с нагромождением неудобных систем, можно решить таким вот путем. Подключаете неудобные системы к интеграционной платформе, подключаете к ней TLI и получаете информацию из всех информационных систем в одном месте с удобным интерфейсом.
Интеграционную платформу, кстати, можно использовать не только для этой задачи, но и в целом для того, чтобы объединить разрозненные корпоративные приложения в одну комплексную «супер-систему». В системе будет обеспечиваться онлайн-синхронизация данных между приложениями, будут выполняться комплексные процессы, затрагивающие сразу несколько систем, и главное — не будет бардака и неразберихи с данными и справочниками.
Единая среда Иногда работа может начинаться вовсе не с документирования процессов или решения конкретной задачи, а полного выстраивания инфраструктуры с нуля.Для ДИТа Москвы мы выполняли инфраструктурные проекты (проектирование, создание и поддержка инфраструктуры) в рамках организации Единой медицинской системы ЕМИАС и разработку специализированных инфраструктур (среда электронной подписи, например). Всё это с 2011 года. Там очень много всего, в частности, одна из самых больших в мире инсталляций ALT Linux (22 тысячи пользователей, которым полностью доступна единая инфраструктура). Мы вместе с разработчиками ALT находили и правили необычные баги, вызванные масштабом.
Фреймворк Разумеется, разработки корпоративного софта требуют и продуманной инфраструктуры с нашей стороны. Для многих процессов нет (и не может быть) готовых продуктов. Та же система делопроизводства в судах и арбитражах или в избирательных комиссиях — хороший тому пример.Поэтому периодически мы разрабатываем информационные системы с нуля. Это может быть как самостоятельное решение, так и кусочек IT-инфраструктуры заказчика, закрывающий какие-то процессы и интегрированный с другими системами.
По большей части корпоративные информационные системы с точки зрения архитектуры достаточно похожи. Есть общие абстракции потоков данных (ввод-изменение-отчёт). Есть GUI-клиенты, где юзер работает с данными. Это могут быть как «толстые», так и веб-клиенты. Тут тенденции повторяют общие тренды отрасли: когда-то давно были веб-клиенты на asp, потом толстые клиенты на .NET, потом опять веб. Сейчас к последним добавляются еще мобильные клиенты.
Несмотря на то, что решение требуется полностью кастомное, иногда оно может быть реализовано на какой-то коробке, типа портала или crm. Но чем больше кастома, тем в этом меньше смысла.
Так как кастомными системами мы занимаемся давно, то процесс поставлен. Никто не пишет совсем с нуля. Есть фреймворки. Они были и для ASP, и для .NET, Java и Web«a. Основная идея в том, что свой фреймворк позволяет пройти полный цикл: от «рисования» модели сущность-отношение до GUI.
За считанные дни можно выкатить типовой приклад — сюда данные вводятся, вот так валидируются, обрабатываются, сюда складываются, здесь выводятся. Можно сесть с заказчиком и показать работающее приложение. Как правило, в этот момент и заказчик доформулирует требования (что решает проблему «ой, а у меня ещё одна фича» перед релизом) и мы лучше понимаем, что точно хочет заказчик. С полным ТЗ редко кто приходит, чаще — с потребностью или критериями решения задачи.
Как говорится, «быстро — не значит качественно». Полученное приложение будет иметь типовой интерфейс, ориентированный на модель, а не на процессы. Конечно, есть большой соблазн так и оставить (работает ведь). Кстати, если это какой-то административный интерфейс, которым пользуется два человека (и оба не начальники), то можно так и оставить. А для серьезной системы, конечно, начинается кастомизация. Но мы не модифицируем «что-то внутри» (как в подходе с коробочными системами), а просто программируем (.net/java/javascript), используя api библиотек, входящих во Фреймворк. Т.е. начальное типовое приложение — это лишь поведение по умолчанию при отсутствии кастомизации. Поэтому конечный результат прямо пропорционален затраченным усилиям команды разработчиков проекта.
Рабочий инструмент разработчика для создания модели структуры данных
Пример тестового приложения на базе фреймворка для управления опросами и голосованием:
Итого Мои коллеги регулярно делают такие вещи как управление ВКС, контроль тренировок перед выборами, фиксация судебных заседаний, консолидация данных о клиентах банка из разных подсистем, логика работы колл-центра, делопроизводство и даже оптимизация раскладки денег в банкоматах — в общем, в задачах есть всё, что угодно. И, несмотря на все экономические и политические условия, услуги и собственные разработки — это то, что при наличии экспертизы, будет востребовано и дальше.В отличие от обычных решений, начиная с размера среднего бизнеса, практически ни одна установка не обходится без того, чтобы минимум месяц собирать информацию о том, что за задача, как она должна решаться, кто участвует в процессах и так далее. Мы задаём вопросы, чертим огромные диаграммы, проверяем их, носим прототипы, общаемся, участвуем в переговорах (когда каждое подразделение старается получить себе какой-то функционал или контроль над процессом), общаемся со множеством руководителей и в итоге выкатываем решение, которое решает задачу и всех устраивает (по возможности). А потом обучаем людей им пользоваться, если это нужно, и поддерживаем.
Разумеется, «тяжелый» софт — это море организационной работы. Самый важный навык — умение получать данные и превращать их в строчки ТЗ. Умение думать за заказчика в плане того, что будет дальше после внедрения и снимать проблемы, которые неизбежно появились бы в будущем. Длинные, мучительно сложные согласования — часть нашей работы. Стандарты, пошаговое документирование, сертификация, тонна бумаги на проект — тоже. Нужно следить за тысячами вещей, и мы, конечно же, автоматизируем для себя и эти процессы внутри компании. Есть и всякие особенности вроде контроля работы грузчиков с сервером, где будет крутиться приклад — тоже, а то они его уронят, и внедрение отложится на 2–3 месяца.
Разумеется, процесс редко останавливается на внедрении. Требования заказчика меняются, меняется окружающая обстановка, нужны новые фичи, доработки, всплывают баги при очень нестандартных ситуациях — в общем, полный набор.
Это тяжело, но того стоит, потому что когда на выходе работающий продукт — довольны все.
