« Назад

27.04.2022 Антон Иванов, Citeck: Проблемы у многих компаний сегодня потому, что они поставили себя в полную зависимость от вендора

Об импортозамещении в области корпоративного ПО говорили давно. Однако события последних недель резко изменили ситуацию. О том, какие тенденции главенствуют сегодня в сегменте BPM-систем, каким образом они меняют требования заказчиков, TAdviser рассказал Антон Иванов, основатель и генеральный директор компании Citeck.

Антон, на какие риски сегодня надо обращать внимание в первую очередь?

Антон Иванов: Необходимо проанализировать всю совокупность рисков, связанных с зависимостью от иностранных вендоров. Если раньше при принятии решения оценивали стоимость, технические характеристики и скорость внедрения в основном, но сегодня параметров стало существенно больше. К выбору новых ИТ-решений теперь нужно подходить с точки зрения того, как вендор сможет продолжить работу в текущих условиях, будет ли обеспечивать поддержку своего ПО, как продукт будет развиваться, насколько он зависим от иностранных компонентов, поставщиков и т.д.

А если говорить о тех проектах, которые были начаты, но не были завершены, и, скорее всего, не смогут быть завершены в условиях санкций, то тут требуются партнеры, способные подхватить такие проекты и выполнить их в рамках прежнего бюджета и в минимальные сроки. В этом плане, конечно, нужны решения, которые обеспечивают быстрый старт.

Кроме того, мне кажется, пришло время задуматься и о вот каком моменте: проблемы у многих заказчиков сегодня именно потому, что они годами делали выбор в сторону решений по типу lock-in, т.е. использования частного ПО с закрытым кодом. Фактически они поставили себя в полную зависимость от конкретного вендора. А зарубежный вендор взял и ушел, оставив подвешенными в воздухе вопросы о продлении лицензий, поддержке и пр. или иногда сразу отказав в любом сотрудничестве. Так стоит ли наступать на те же грабли снова, опять делая выбор в пользу решения lock-in, только теперь уже отечественного? Это тоже риски, которые стоит учитывать. На мой взгляд, сегодня корпоративные заказчики должны обратить пристальное внимание на отечественные open source решения, потому что именно подход open source в современных условиях становится очень интересным вариантом для российских компаний, гарантирующим независимость будущих систем и будущего ИТ-инфраструктуры в целом от любых решений партнеров.

Ну и на фоне происходящего очень забавно наблюдать, как быстро меняют свое позиционирование некоторые игроки рынка: еще в январе они гордились, что работают на западных рынках по западным стандартам и с зарубежными технологиями, а сегодня уже декларируют, что все без исключения у них отечественное.

О важных особенностях BPM-платформы

Возможно, имеет смысл перейти на системы или платформы другого класса? Например, выбрать другой элемент эволюционной цепочки ЭДО-ECM-CSP?

Антон Иванов: Знаете, разделение на классы: BPM, ECM, Case Management и т.д. – это принято, скорее, у маркетологов и аналитиков рынка. А многие заказчики, для которых мы выполняем BPM-проекты, их так вовсе не называют. Для них это может быть проект docflow или портальный проект и т.д. Для них главное – бизнес-требования, которые нужно реализовать, а не класс используемой платформы.

И в этом вопросе рынок как раз начал ценить и использовать open source решения. В последние годы в тендерах все активнее прописывается участие именно такого ПО. При этом нужно отдавать себе отчет, что популярные BPMS на основе СПО, например, Flowable, Camunda, Activity и т.д., это именно движки, а не полноценная платформа: неплохие редакторы процессов, среды для исполнения процессов, частично процессная аналитика, но только уже в платных версиях. Но этого недостаточно для реализации полноценных бизнес-задач.

Заказчикам в любом случае придется либо самостоятельно с использованием указанного ПО разрабатывать свою собственную платформу и удобный пользовательский интерфейс, что потребует немалых затрат времени и бюджета, либо использовать какую-либо платформу, в составе которой есть BPM-движок. Ведь сам по себе BPM-движок без поддержки работы с данными не представляет большой ценности, потому что в любом случае нужно будет обеспечивать хранение и взаимодействие с данными, интеграции и тд. Кроме того, в ходе процессов порождаются разнообразные документы, требуются производственные календари, функциональность замещения и делегирования и т.д. Значит, нужно говорить о платформенных решениях, которые включают как BPM-часть, так и другие необходимые составляющие для реализации бизнес-процессов.

BPM-системы оказываются в центре этой информационной структуры?

Антон Иванов: Да, BPM как концепция изначально предполагает управление всеми процессами предприятия. Она должна выступать в роли единого связующего звена между разнообразными ИТ-системами. Другое дело, что далеко не каждая BPM-платформа позволяет это реализовать на практике. Чтобы соответствовать этой роли, платформа должна обладать хорошими интеграционными возможностями, причем, с минимальным программированием. Она должна иметь в своем составе ECM-решение для работы с контентом. Должна иметь дружелюбный портальный пользовательский интерфейс.

О роли и месте функционала low-code

Минимальное программирование, которое Вы упомянули, это элементы low-code? Насколько важен этот аспект корпоративной платформы?

Антон Иванов: Мы являемся сторонниками low-code подхода. Но low-code – это не «серебряная пуля». Он не может гарантировать: теперь у нас каждый бизнес-пользователь – сам себе разработчик, и с их помощью мы создадим все решения. У бизнес-пользователей есть свои собственные задачи, которые они должны решать в первую очередь. Поэтому наша концепция BPM-платформы базируется на том, что с ней работает именно бизнес-аналитик, то есть человек, который, с одной стороны, понимает, что именно хочет заказчик, а с другой стороны, благодаря low-code, может быстро показать результат.

Конечно, этот подход позволяет сократить бюджет и сроки внедрения, особенно в контексте нынешней нехватки ИТ-специалистов на рынке, как в России, так и в мире. Но при этом low-code зачастую загоняет разработчиков в определенные рамки.

Если вы посмотрите на маркетинговые материалы вендоров, то увидите: все и везде пишут, что можно быстро и легко автоматизировать почти любой процесс. Но когда дело доходит до реальных ситуаций, оказывается, что процесс, который в рекламной брошюре состоит из нескольких шагов и небольшого количества полей в форме, в реальной жизни становится гораздо сложнее. И вот здесь проявляются ограничительные рамки low-code решений. Вплоть до того, что порой проще и дешевле реализовать задачу вообще без использования платформы.

Об организации связи процессов и данных для быстрого старта

Вам удалось преодолеть эти рамки?

Антон Иванов: Мы в нашей платформе Citeck ECOS предлагаем, на мой взгляд, редкий для рынка подход, который сочетает, с одной стороны, все преимущества low-code возможностей, которыми пользуются бизнес-аналитики, а с другой стороны, мы не устанавливаем ограничений в средствах разработки для реализации более сложных задач. Как это достигается?

Мы предполагаем, что для быстрого старта аналитик параллельно со сбором требований начинает в системе моделировать процесс, создавать модель данных, пользовательские формы и т.д. И тогда, в отличие от классического «водопадного» метода реализации ИТ-системы, практически сразу, параллельно с написанием технического задания, можно настраивать процессы непосредственно в реальной системе. Иными словами, заказчик сразу видит работающий прототип всего решения. При этом черновик технического задания генерируется платформой на основе произведенных настроек. Конечно, это значительно сокращает период согласования ТЗ и минимизирует недопонимание.

Описанный подход позволяет еще на старте учесть все те нюансы конкретной ситуации, которые могут кардинальным образом повлиять на реализацию всего проекта.

После этого к проекту подключаются программисты. Благодаря микросервисной архитектуре платформы, они могут разрабатывать бизнес-логику на любом языке программирования. Иными словами, если у заказчика есть штат своих специалистов, владеющих определенными технологиями, они могут пользоваться привычными средствами разработки, управления версиями кода и т.д. И при этом, подчеркну, полноценно взаимодействовать с платформой, т.е. мы функционально и идеологически разделяем бизнес-аналитика и разработчика: первый работает с визуальными настройками через WEB-интерфейс, второй – с кодом.

Каким образом платформа реализует связь процессов с реальными данными?

Антон Иванов: Возможность работы с различными источниками данных – это, на мой взгляд, выдающаяся особенность Citeck ECOS. Так как решение базируется на микросервисной архитектуре, то у каждого микросервиса может быть свой источник данных. Поэтому для платформы нет внешних данных в принципе, для нее все данные – это данные первого сорта, которыми она может свободно оперировать, в том числе с использованием low-code возможностей. Нам не нужно, в отличие от большинства BPM-решений, импортировать данные из сторонних систем в свое хранилище для работы с ними. Платформа может работать «на лету» с любыми данными, которые содержаться в различных информационных системах заказчиков. Почему это важно? Приведу пример из практики.

Недавно мы запустили в промышленную эксплуатацию проект, в котором осуществляется работа с данными, хранящимися в существующей корпоративной информационной системе. И этих данных порядка нескольких десятков терабайт. Понятно, что если следовать классическому подходу и импортировать их в платформенное хранилище, то это ляжет огромной нагрузкой, как на разработчиков, так и на ИТ-ландшафт компании. А мы практикуем другой подход: когда пользователь запрашивает какие-либо данные, мы берем информацию из корпоративной системы заказчика, берем данные из нашей системы, соединяем их и отображаем в едином интерфейсе. Иными словами, пользователь даже не задумывается о том, из какого источника что берется, − для него это абсолютно прозрачно. Важно, что все эти данные он может просмотреть, не переключаясь между различными окошками и различными системами. Причем, мы можем, как отображать данные, так и изменять их, то есть полноценно обеспечивать всю работу с ними, включая разграничение прав доступа.

А для поддержки новой системы достаточно просто написать для нее адаптер. В состав платформы уже входят адаптеры к наиболее распространенным ИТ-системам.

В этих процессах помогает система управления мастер-данными (MDM), которая входит в состав платформы?

Антон Иванов: Да. Причем, мы не предлагаем заменить существующие MDM-системы заказчика. Мы стремимся облегчить работу с этими данными − предложить дружелюбный и понятный пользовательский интерфейс, в котором пользователь сможет создавать новые мастер-данные, изменять существующие, а система будет ему в этом помогать. Ведь в работе с любыми данными всегда существует много разных правил, и пользователь обычно не помнит их все.

Отмечу еще, что в составе платформы есть ПО адаптивного Case-менеджмента Adaptive Case Management, ACM, которое позволяет управлять кейсами непосредственно в нашей системе. Таким образом, оба решения: BPM и ACM – в составе платформы Citeck ECOS дополняют друг друга. Это позволяет, например, реализовать верхнеуровневый процесс в виде кейса, который дает возможность управлять неопределенностью, имеющейся в реальной жизни. А процессы более низкого уровня моделируются в виде BPMN-диаграмм и оркестрируются с помощью Case-менеджмента. Иными словами, если мы четко знаем последовательность шагов, которая точно приведет нас к результату, то можем смоделировать этот процесс в виде BPMN-диаграммы. Но в реальной жизни могут появляться какие-то сторонние внутренние или внешние факторы, которые в принципе могут изменить всю логику работы процесса. И в этом случае на помощь приходит Case-менеджмент.

Об особенностях автоматизации процессов

Немаловажная часть BPM платформ − функциональные решения. Как они выглядят сегодня в русле тенденции сквозной автоматизации бизнес-процессов, включая механизмы роботизации бизнес-процессов (RPA)?

Антон Иванов: Именно для того, чтобы обеспечить быстрый старт проекта, мы предлагаем более полутора десятка готовых функциональных модулей, которые заказчик может использовать, в том числе, дорабатывать, адаптировать под свои требования. Иными словами, можно взять платформу и начать разработку с нуля, то есть смоделировать процесс и запустить его. А можно взять готовое решение и просто его настроить.

Ведь несмотря на то, что с одной стороны, каждая организация уникальна, есть базовые процессы, которые путем небольшой доработки можно довольно быстро приспособить под бизнес большинства компаний. Это позволяет значительно сократить сроки и бюджет внедрения. В наших планах на этот год запуск магазина приложений. Через него эти решения можно будет быстро установить в систему. Будем и дальше продолжать развивать готовые решения, как самостоятельно, так и с помощью партнеров.

Что касается роботизации процессов, она может помочь, если, например, заказчик не готов создавать интеграционные взаимодействия с другими системами. В этом случае роботизация может сократить ручной труд пользователей. При этом отказываться от BPM и строить процесс полностью на основе концепции роботизации не имеет смысла, так как в любом случае это будет временным решением. Почему? Потому что в случае с RPA в конечном итоге заказчик не понимает, как работает конкретный процесс. А вот BPM, напротив, позволяет взглянуть на него сверху и управлять им. Это важно. Ведь обычно для BPM-решений лучшей практикой является реализация сквозных процессов, поскольку чаще всего процессы компании не изолированы: они начинаются, скажем, от заказа клиента, переходят к поставщикам и опять возвращаются к клиенту. BPM дает возможность оценить этот процесс в целом, увидеть и убрать узкие места в каждой его части. В отличие от механизма RPA, который может решать только сиюминутные задачи по сокращению ручного труда.

Как в рамках одной платформы можно учесть специфические потребности автоматизации процессов, свойственные как крупным, так и небольшим компаниям?

Антон Иванов: Поскольку у крупных компаний бизнес-процессы обычно более сложные и разнообразные, мы предлагаем им использовать готовое функциональное решение и адаптировать его к конкретному бизнесу, либо реализовать свое функциональное решение средствами платформы. А небольшим компаниям будет полезно использование готового модуля без каких-либо существенных доработок или использование облачной версии платформы, возможно, с небольшими настройками. Причем, такие настройки обычно можно реализовать с помощью low-code без программирования.

Стоит еще упомянуть о том, что в компаниях любого размера, помимо основных бизнес-процессов, на которые обычно ориентируются средства BPM, есть множество других процессов – достаточно мелких, но которые съедают большое количество рабочего времени сотрудников. Это, скажем, коммуникации, которые происходят по электронной почте: их много, их очень сложно контролировать, данные и документы теряются, пользователи не отвечают на письма в нужные сроки и т.д. Вроде бы вещи не существенные, но зачастую могут негативно влиять на основные бизнес-процессы компании, даже если те хорошо автоматизированы. Про такие процессы не стоит забывать. Тем более, что они обычно достаточно простые, и с помощью low-code инструментов их можно реализовывать быстро в рамках скромного бюджета. А пользы от такой мелкой автоматизации в итоге может оказаться не меньше, чем от автоматизации основных бизнес-процессов.

Можете привести пример такого проекта?

Антон Иванов: Да, конечно. Пример – один из крупнейших производителей потребительских товаров, с которым мы работаем уже более пяти лет. Начинали как раз с крупных процессов – внедрения ЮЗЭДО, автоматизации финансовой деятельности. А потом перешли к таким вот небольшим процессам, например, управления кредитным лимитом клиентов или управления рекламациями. К настоящему моменту мы автоматизировали в общей сложности около 40 различных бизнес-процессов, которые происходили как в разных информационных системах, так и в электронной почте, таблицах Excel, с помощью других подручных средств.

О специфике open source в современных реалиях

Давайте пристальнее посмотрим на свободное ПО. Нынешний этап корпоративной информатизации проходит под знаменем open source. Что можно сказать о разнообразии программных решений, которые создаются на базе одного популярного варианта исходного кода и безопасности такого решения в свете сегодняшней ситуации с рисками и угрозами в области ПО?

Антон Иванов: Во-первых, надо отметить, любой современный продукт использует open source-компоненты. Я уже приводил пример популярного движка Camunda – он решает только часть узкоспециализированных задач. Поэтому два продукта, которые имеют в своем составе одно и то же open source решение, могут отличаться принципиально.

Что касается безопасности, то в любом коде есть ошибки и уязвимости. Однако если код открыт, и у вендора или заказчика есть соответствующая экспертиза, то эти ошибки гораздо проще обнаружить и исправить, чем те же самые ошибки в закрытом продукте. Ведь в последнем случае приходиться полагаться исключительно на то, что вендор эту ошибку найдет и быстро выпустит «заплатку».

Еще одно преимущество открытого кода заключается в том, что помимо ручной проверки, можно использовать разнообразные инструменты анализа кода, которые имеются на рынке. Они проверяют ПО на наличие как ошибок разработки, так и распространенных уязвимостей. В случае закрытого кода такой возможности нет.

Самое страшное, что может случиться с лицензией open source продукта − вендор может выпустить новую версию решения не под open source лицензией, а под закрытой лицензией. Но даже в этом случае, если у компании есть соответствующая экспертиза, она может продолжать пользоваться открытой версией продукта, поддерживать его и развивать.

Что касается нашей компании, то мы являемся open source компанией, более 90% нашего кода опубликовано под открытой лицензией LGPL. Это подразумевает, что можно зайти на наш сайт, скачать ПО и изучить его полностью, как функционал решения, так и его код. Для Enterprise версии мы предоставляем 100% исходного кода. И многие наши крупные заказчики, как отечественные корпорации, так и иностранные, уже воспользовались этой возможностью, так что наш код многократно проверен сотрудниками ИБ и признан безопасным. Таким образом, наши заказчики могут быть абсолютно спокойны.

Об изменениях в компаниях заказчиков после внедрения платформы

Любому заказчику хочется, чтобы приобретаемая платформа решала не только сегодняшние бизнес-задачи, но и те, которые возникнут завтра. Можно ли этого достичь?

Антон Иванов: Конечно, при выборе платформы заказчик должен принимать во внимание дорожную карту развития продукта. Потому что, если ее нет, то продукт, который сегодня вполне конкурентоспособен, через несколько лет перейдет в разряд legacy-систем. В этом смысле поставщик, исповедующий «открытый» подход, находится в преимущественном положении. Например, у нас открытой является не только большая часть кода, но и система управления нашей разработкой. Заказчик может в любой момент посмотреть, какие задачи сейчас в работе, как выглядит дорожная карта развития продукта, когда ожидаются ближайшие релизы и т.д.

Приведите, пожалуйста, примеры продвинутых проектов, которые уже выполнила компания Citeck на базе своей BPM-платформы ECOS.

Антон Иванов: Мы давно работаем с российским подразделением компании General Electric. Недавно завершили довольно интересный проект, который актуален, думаю, практически для любой крупной компании. Возможности реализованной системы позволяют разграничить работу с ней для внутренних и внешних пользователей − сотрудников заказчиков, поставщиков и т.д. Иными словами, мы реализовали бизнес-процесс, который начинается внутри компании, а затем переходит в часть системы, которая находится в открытом контуре. Та информация, с которой работают сотрудники GE, находится в закрытом контуре, а в открытом контуре подключаются клиенты, поставщики и выполняют необходимые действия. Причем, подключаются по сети Интернет, через свои учетные записи с соблюдением всех требований информационной безопасности.

Отмечу, что создание такого решения не потребовало дополнительной существенной разработки, так как архитектура системы изначально предполагает такой вариант использования. Поэтому проект удалось осуществить в сжатые сроки.

Думаю, что такая архитектура цифровой бизнес-платформы весьма актуальна в нынешних условиях информационных атак на различные корпоративные ресурсы, когда многие заказчики решают, чем пожертвовать. Оставить существующую систему в открытом контуре, согласившись с риском, что она может перестать работать? Или разместить систему в закрытом контуре, ограничив возможности пользователей по доступу в систему? Реализованный в GE подход позволяет значительно снизить риски без ограничений для пользователей.

Еще один интересный проект мы недавно выполнили для крупной металлургической компании. Там речь идет о внедрении Citeck ECOS в качестве единой шины для интеграции различных учетных систем предприятия с ЮЗЭДО-провайдерами. Вместо того, чтобы интегрировать каждую учетную систему отдельно со всеми ЮЗЭДО-провайдерами, мы предложили использовать единое решение, чтобы через него пользователи могли обмениваться юридически значимыми документами. Более того, мы снизили нагрузку на эти системы, потому что вся предварительная работа: согласование, подписание документов – происходит на базе нашей платформы, а в учетную систему передаются уже финальные данные – подписанные документы.

Коннекторы к различным системам уже реализованы, поэтому достаточно выполнить интеграцию с нашей платформой, что, конечно, радикально упрощает проект. И все основные операции происходят на базе Citeck ECOS. Скажем, не надо реализовывать работу с электронной подписью и т.д.

Все специалисты, занимающиеся внедрением ИТ-систем у заказчиков, знают, что первая реакция пользователей на новую систему – негативная, ведь, как бы ни была она хороша, приходится переучиваться, менять привычный порядок действий, доведенный до автоматизма. Быстрый старт платформы Citeck ECOS может сгладить этот негатив?

Антон Иванов: Конечно, мы постоянно работаем над совершенствованием нашей платформы, в том числе, и над повышением удовлетворенности пользователей. Именно поэтому платформу Citeck ECOS, которой уже семь лет, мы полностью переписали в микросервисной парадигме и выпустили новый пользовательский интерфейс. Это дало существенные результаты, и в части быстродействия системы, и в части удобства пользователей, и в отношении скорости и простоты расширения.

А что касается удовлетворенности пользователей на самом первом этапе внедрения, то – и это знают все, кто работает с ПО – первая реакция, как правило, действительно негативная. Дальше вопрос в том, насколько хорош, интуитивно понятен ваш интерфейс, насколько логично выстроена система и насколько четко, без сбоев и подвисаний, она работает. Если все эти аспекты проработаны, а в ECOS один из самых удобных интерфейсов, которые я встречал, то пользователи быстро адаптируются. И через полгода, год этот показатель увеличивается: пользователи привыкают к новой системе, и показатель удовлетворенности растет.

Конечно, в этом большую роль играет наша методология внедрения, которая в целом соответствует принципам Agile. На старте проекта мы не только даем заказчику ТЗ, а показываем, как минимум, работающий прототип уже в реальной системе. Очень показателен в этом плане опыт общения с одним из наших крупных заказчиков: первый проект мы выполняли по классической «водопадной» схеме, а потом предложили нашу методологию быстрого внедрения с прототипированием процессов на начальном этапе – пользователи были очень довольны.