Сергей Курьянов, директор по стратегическому маркетингу компании «ДоксВижн»

«Коробки и платформы – объединение возможно»

СЭД как предметная область прикладных решений испытывает борьбу двух подходов  – «коробок» и «платформ». Что лучше – быстро внедряемая готовая функциональность или возможность реализовать любую?

Приняв решение о внедрении СЭД, пользователь оказывается на распутье, и от его решения зависит, каким путем пойдет развитие автоматизации управления документами, задачами и бизнес-процессами в течение долгих лет – такие системы не меняются ни каждый год, ни даже каждые пять лет.

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

Однако третий путь – возможен!

Чтобы найти его, давайте еще раз кратко перечислим плюсы и минусы коробок и платформ, это поможет нам найти этот идеальный третий путь.

Коробочные решения – плюсы

1) Готовое решение «в одном флаконе» с готовыми регламентами (культура управления «прошита», не надо ее мучительно создавать у себя).

2) Быстрое внедрение, часто возможное собственными силами заказчика: просто установить, настроить справочники, провести обучение и работайте! С этим связаны и невысокие затраты на работы по внедрению, гораздо легче планируемые в случае коробки.

3) Надежная оценка рисков – если коробка успешно внедрена в похожем предприятии, то и у нас внедрение будет успешным с высокой вероятностью.

4) Невысокие затраты на сопровождение. Собственно сопровождение сводится в основном к установке патчей с исправленными ошибками и функциональными доработками, как правило, связанными с изменениями в законодательстве о ДОУ.

5) Это чисто «айтишный» проект. Ответственность за выбор коробки по функциональности несет бизнес-уровень, дальше все делают IT-pro, минимально взаимодействуя с бизнесом в процессе настройки и обучения.

6) Все работает быстро и требует мало ресурсов от инфраструктуры – прямое программирование бизнес-логики и интерфейсов позволяет написать весьма оптимальный код.

Коробочные решения - минусы

1) Готовые регламенты – вещь полезная, но в них почти ничего невозможно изменить, настройки чисто параметрические. Для малых предприятий это терпимо, поскольку то, что «не влезает» в регламенты, легко поддается «бумажному» управлению. Но для средних, и особенно крупных предприятий объем «бумажных исключений» сводит на «нет» все плюсы от автоматизированных типовых регламентов.

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

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

4) Расширение универсальности коробки для более широкого покрытия рынка приводит к ее усложнению, в том числе по интерфейсам. Ненужные закладки и поля в карточках не только снижают юзабилити, но и служат источником ошибок – пользователь легко может ввести что-то «не туда» или выбрать «не то». В результате, по мере зрелости коробки возникает парадоксальная ситуация – в ней одновременно и слишком много всего для всех, и слишком мало для каждого.

5) Интеграция коробки с другими ИТ-системами предприятия практически невозможна. Либо модуль интеграции выпускается вендором и представляет расширение коробки, либо его нет - и об интеграции можно забыть. Даже если вы знаете недокументированный API сервера приложений коробки, делая свой шлюз, вы вступаете на минное поле – никто не сможет сопровождать систему, в которую «неизвестные программисты залезли грязными руками». Это увеличивает риски интеграции многократно.

Платформы – плюсы

Для начала заметим, что многие плюсы платформ – это зеркальное отражение минусов коробок.

1) Неограниченная гибкость, в первую очередь, по бизнес-логике и регламентам;

2) Менять можно «на ходу», не дожидаясь выхода новой версии платформы;

3) Изменения делаются часто вообще без программирования, визуальными средствами;

4) Интерфейс может быть изменен в соответствии с автоматизируемым сценарием использования -  только то, что нужно, и ничего лишнего;

5) Интеграция – либо через документированный и поддерживаемый разработчиком API сервера приложений, либо через шлюзы Workflow. Набор шлюзов можно расширить, для этого не надо программировать бизнес-логику, реализуемую в Workflow и сервером приложений, надо только написать конвертор к данным и обработчик событий.

Платформа – минусы

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

2) Риск того, что внедренная успешно в одной организации платформа (или ее внедренец) не справится в другой – гораздо выше, чем в случае коробки.

3) Решения оказываются гораздо более тяжелыми и менее производительными, предъявляют значительно более высокие требования к рабочим станциям, серверам и вычислительным сетям.

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

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

Третий путь – гибкая коробка на платформе

Пройти между Сциллой коробки и Харибдой платформы, тем не менее, возможно. На наш взгляд – это путь выпуска гибких типовых приложений – «гибких коробок».

Что отличает гибкую коробку от платформы и от обычной коробки?

1) Гибкая коробка включает все базовые объекты приложения, созданные разработчиком платформы с максимальной возможной оптимизацией по производительности.

2) Она включает в себя также базовый уровень бизнес-логики (выборку и представление контекстных данных базовых объектов), реализованный на уровне скриптов.

3) Бизнес-логика процесса обработки объектов приложения, а также интерфейсы карточек приложения открыты для изменений средствами штатных «конструкторов» - встроенных в платформу инструментов быстрой разработки решений.

4) В «гибкой коробке» в момент поставки реализован базовый уровень простого сценария использования (универсального в силу простоты, а не функциональной избыточности), что обеспечивает ее быстрое внедрение в рамках этого сценария с параллельной «достройкой на ходу», по мере осознания и развития специфических требований заказчика.

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

Для ясности приведем пример. Главным направлением развития Docsvision 5 было резкое увеличение гибкости платформы и мощности инструментов быстрого создания решений.

В платформе был реализован базовый набор объектов (документ, задание, нерегламентированное согласование, бизнес-процесс), реализующий простейший сценарий СЭД «безканцелярского» типа. Практика показала, что, несмотря на удивительную простоту, в ряде случаев этого оказывается достаточным для успешного начала эксплуатации на довольно крупных предприятиях.

Далее был проведен анализ более сложных сценариев, характерных для «канцелярской» и переходных форм организации документооборота. Были выделены следующие базовые объекты:

  • Резолюция как форма распределения задач и контроля их исполнения в контексте конкретного документа;
  • Номенклатура дел – «шлюз» к управлению «бумажным» архивом;
  • Простые процессы «рассмотрения» и «исполнения» документа, набор простых интерактивных отчетов по контролю исполнительской дисциплины и состояния исполняемых документов;
  • Регламентированное согласование (маршрут), обеспечивающее возможность жесткого исполнения регламента с одной стороны, возможность циклов, гибкость по отношению к конкретным ситуациям и набор специальной функциональности вроде этапа «консолидации», когда надо из нескольких вариантов документа, возникших при его параллельных правках в процессе согласования, аккуратно «собрать» один обобщающий.

В результате появилось «Делопроизводство» как типовое приложение, обеспечивающее автоматизацию канцелярской формы документооборота с любыми нюансами, отражающими специфику заказчика, и еще один новый конструктор – «Конструктор согласований».

Вышедшее вслед за конструктором типовое приложение «Договоры» фактически содержало типовую карточку договора (открытую для редактирования средствами Конструктора карточек).

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

Новый уровень типовых решений в формате «гибкой коробки» оказался возможным благодаря следующим особенностям платформы Docsvision 5:

1) Набор базовых объектов, на котором «хардкодом» сделан ряд наследуемых при дальнейшем конструировании функций, таких, как поддержка ЭЦП (в полном объеме по ФЗ№63), версионность, коллекции файлов в одном документе, управление доступом, регистрация, выдача заданий и т.п.;

2) Встроенная на уровне базовых объектов контекстно-ролевая модель, обеспечивающая описание соответствующей логики – роли пользователя по отношению к данному документу, в данном состоянии, ко всем документам данного вида, связи этого контекста с правами на видимость, редактирование и подписание отдельных полей документа;

3) Встроенная наряду с ролевой моделью машина состояний, позволяющая описывать возможные состояния документа от черновика до размещения в архиве;

4) Наличие визуальных средств быстрой разработки решений – Конструктора бизнес-процессов, Конструктора карточек, Конструктора согласований, а также ряда других конструкторов.

5) Связь Конструктора карточек с ролевой моделью и автоматом состояний, позволяющая без программирования строить интерфейс документа и задания, соответствующий их состоянию и роли пользователя в конкретный момент. Среди прочего, это реализует давнюю мечту руководителей - увидеть при подписании документ, в котором есть только текст и две кнопки: зеленая и красная.

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

Конечно, это не означает, что «гибкая коробка» - волшебная пилюля, которая не оставляет места чистым коробочным решениям. Для малых предприятий они всегда останутся оптимальным выбором, и переход в облака тут мало, что поменяет: большая часть облачных решений - это простейшие коробки.

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