Что такое бизнес конструктор

Обновлено: 04.05.2024

Почему в век высоких технологий и искусственного интеллекта основным инструментом бизнес-консультантов и аналитиков остается excel?

Для ответа на этот вопрос мы провели исследование русскоязычных сервисов и программ, предназначенных для разработки бизнес-планов. Мы- это агентство инвестиционного консалтинга "Цифра".

Какие задачи решаются при составлении современного бизнес- плана?

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

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

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

Считать можно сверху вниз, а можно снизу вверх. В любом случае, нужно знать исходную точку и конверсию на каждом этапе воронки.

- Составление бюджета рекламы и продвижения. В современном бизнес- плане недостаточно просто выделить какой- то бюджет на рекламу.

Особенно это касается интернет- проектов, для торговли это тоже важно.

Бюджет рекламы должен быть разделен на каналы (соцсети, поисковая реклама и тп) и по каждому каналу должен быть сформирован трафик и стоимость.

План продвижения связывается с прогнозом продаж. Реклама должна приводить нужное количество посетителей.

- Вид деятельности. Традиционно бизнес- планы делались для производства, сельского хозяйства, торговли и услуг.

Современный бизнес представлен огромным количеством посреднических и агентских схем монетизации. Онлайн- сервисы, агрегаторы, биржи и тп.

Для разработки финансового плана нужна возможность планировать финансовые потоки в зависимости от схемы монетизации.

- Изменения периодичности в финансовом плане. Добавление или удаление периодов, укрупнение.

- Изменение состава статей доходов и расходов.

- Расчет показателей эффективности. Кроме классических показателей, в современном плане нужно считать юнит- экономику.

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

- Создание небольших презентаций из готового бизнес- плана.

- Возможность делать все это в совместном доступе.

Есть ли сервис, который решает все эти задачи?

Рынок ПО для создания БП очень узок. Мы нашли 5 подобных русскоязычных программ, а демоверсии есть у только у 3. Все 5 сервисов мы сравнили по 14 критериям.

Сервис разработан на базе Project Expert- старейшей программы в России для разработки бизнес-планов.

Для подготовки этого материала компания «Эксперт Системс» предоставила нам бесплатный доступ к полному функционалу сервиса на 1 месяц для всестороннего тестирования. По итогам тестирования представим подробный обзор этого инструмента, сейчас сравним его с другими возможностями, имеющимися на рынке.

ВРЕ24 является облачным сервисом, не требует установки на компьютер, доступен 24 часа в сутки.

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

2. Цена – от 3 тыс. руб. в мес.

3. Совместный доступ – облачный сервис, возможность совместного доступа.

4. Анализ рынка- нет.

5. Виды деятельности - производство, услуги, перепродажа.

6. Изменение и пересчет финансовой модели- в полном объеме.

7. Выгрузка финмодели в Excel – выгружается отдельными блоками, только значения без формул.

8. Воронка продаж – нет.

9. План рекламы и продвижения- нет.

10. Расчет Unit- экономики – нет.

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

Графики генерируются, инфографики нет.

12. Возможность наполнения текстовыми блоками. Можно вносить любой произвольный текст и менять структуру плана.

13. Использование типовых формулировок. Можно создать свои шаблоны, в сервисе встроенных шаблонов нет.

14. Формат готового документа. Возможна выгрузка в DOCX, Excel и PDF.

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

Вывод. Невысокая цена и встроенный функционал позволяют делать типовые планы по традиционным отраслям, рассчитывать эффективность проектов.

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

1. Демоверсия – есть демоверсия с неограниченным сроком доступа, можно изучать готовые примеры, свой проект создать нельзя.

2. Цена – от 110 тыс. руб. в год

3. Совместный доступ – нет.

4. Анализ рынка- нет.

5. Виды деятельности - любые.

6. Изменение и пересчет финансовой модели- в полном объеме. Формулы защищены от редактирования.

7. Выгрузка финмодели в Excel –есть.

8. Воронка продаж – нет.

9. План рекламы и продвижения- нет.

10. Расчет Unit- экономики – нет

11. Визуализация – нет. Возможно настраивать и выгружать готовые таблицы в текстовый документ.

12. Возможность наполнения текстовыми блоками. Нет.

13. Использование типовых формулировок. Нет.

14. Формат готового документа. Возможна выгрузка в DOCX, Excel и PDF.

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

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

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

Продукт содержит шаблон бизнес-плана с примерами реальных проектов и описанием заполнения и программу для расчётов в формате Excel для разработки всех необходимых финансовых показателей.

1. Демоверсия –нет.

2. Цена – от 249 руб. в месяц.

3. Совместный доступ – нет.

4. Анализ рынка- нет.

5. Виды деятельности – любые.

6. Изменение и пересчет финансовой модели- в полном объеме. Формулы защищены от редактирования.

7. Выгрузка финмодели в Excel –есть.

8. Воронка продаж – нет.

9. План рекламы и продвижения- нет.

10. Расчет Unit- экономики – нет

11. Визуализация – нет. Возможно настраивать и выгружать готовые таблицы в текстовый документ.

13. Использование типовых формулировок. Есть готовый шаблон бизнес- плана, но тексты нужно писать самостоятельно.

14. Формат готового документа. Возможна выгрузка в DOCX, Excel и PDF.

Вывод.

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

Текстовые блоки и визуализация не проработаны.

Недостаток- отсутствие демоверсии и примеров разработанных планов.

Цифровой конструктор бизнес-модели (DBMC - Digital Business Model Constructor) предназначен для проектирования, описания и развития бизнес-модели компании на основе шаблона CANVAS Остервальдера-Пинье. Конструктор бизнес-модели - это простой и удобный инструмент, облегчающий построение, анализ и планирование вашего бизнеса.

Вы можете использовать DBMC индивидуально или в ходе стратегических и рабочих сессий, проводимых в составе управленческой команды предприятия. В результате заполнения шаблона Вы получаете текущую ("как есть") и целевую ("как надо") бизнес-модели компании.

В чем ценность конструктора?

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

После начала работы Вы переходите в шаблон бизнес-модели , состоящий из девяти блоков:

1. Виды деятельности.
2. Ключевые ресурсы.
3. Ценностное предложение.
4. Взаимодействие с клиентами.
5. Каналы сбыта.
6. Целевые группы клиентов.
7. Партнеры и поставщики.
8. Структура доходов.
9. Структура расходов.

Далее, переходя по ссылкам, Вы можете заполнить каждый блок шаблона бизнес-модели самостоятельно или с помощью справочников , копируя необходимые элементы в соответствующее рабочее поле. Рабочие поля шаблона заполняются "стикерами" с названиями элементов бизнес-модели. При этом Вы можете использовать стикеры разных цветов: желтый - "как есть", но планируем сохранить и развивать; оранжевый - "как есть", но планируем развивать в приоритетном порядке; розовый - "как есть", но планируем сократить или ослабить; красный - "как есть", но планируем отказаться; зеленый - пока нет, но планируем создать в течение 1-3 лет (ОБР - область ближайшего развития); голубой - пока нет, но планируем создать в течение 4-5 или более лет (ОДР - область дальнего развития).

ЧТО ВЫ ПОЛУЧАЕТЕ В ИТОГЕ?

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

Что это вам дает? Много чего. Во-первых, по ходу заполнения шаблона руководители и собственники начинают лучше понимать и осознавать природу и тонкости своего бизнеса. Вместо отдельных деревьев, мы начинаем видеть лес в целом. И в процессе этой работы возникают интересные идеи и инсайты по развитию и "перезагрузке" компании. Во-вторых, заполнив шаблон "как есть" (желтые, оранжевые, розовые и красные стикеры) и "как надо" (зеленые и голубые стикеры), вы по сути, но в удобной и наглядной форме получаете стратегический план развития вашей компании. В-третьих, на основе текущей и целевой бизнес-модели вы сможете грамотно и точно сформулировать систему целей организации, разработать ее процессную и административную структуру. Если бизнес-модель предварительно не построить, то система управления компанией будет напоминать "дом на песке". При малейших колебаниях она просто развалится, как карточный домик. В-четвертых, на основе целевой бизнес-модели, вы можете разработать портфель проектов и поручений по развитию предприятия и затем перейти к их реализации. Так вы создаете будущее вашего бизнеса. Как известно, точкой входа в будущее является настоящее. Разработав бизнес-модель здесь и сейчас, вы открываете для вашей компании осознанный путь в будущее. Оно того стоит.

Олег Кулагин, автор и разработчик.

Вопросы, замечания, пожелания:

КАК ПРИОБРЕСТИ?

Стоимость конструктора - 29900 рублей.

1. Перевод 29900 рублей на на карту MИР Сбербанка РФ:
2202 2016 1712 5626. Кулагин Олег Анатольевич. Обязательно укажите ваше имя и электронный адрес для файлов конструктора.

2. Оплата по счету на ИП Кулагин О.А. Счет готов выставить по вашему требованию.

Да, чуть не забыл. Покупателям конструктора бизнес-модели положены шикарные подарки !

Это моя цифровая книга "Целевое управление компанией. Как построить организацию, заточенную на результат" и библиотека показателей деятельности предприятия KPI-Library , содержащая описание более 500 наиболее важных показателей для управления компанией и мотивации персонала.

Желаю Вам успехов и достижения целей вашего бизнеса!

Олег Кулагин, основатель и руководитель KPI Service Group , фасилитатор стратегических сессий, консультант по управлению.

Мы создаём онлайн-конструктор учетно-отчетных систем, который позволяет без программирования создать веб-приложение. Помимо нашего продукта на рынке есть еще десятки конструкторов как от небольших и средних компаний (Zoho Creator, QuickBase, Caspio, Zengine), так и от гигантов (Oracle Application Express, Microsoft PowerApps).

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

О конструкторах баз данных и бизнес приложений

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

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

В основном из-за простоты, гибкости и отсутствия необходимости в программировании (но при этом доступности VBA), в 90-е и 2000-е с помощью Excel и Access создавались миллионы учётно-отчётных приложений. Учётная система может начинаться с небольшого приложения из 3 таблиц и пары форм. В случае востребованности приложения бизнесом, оно начинает обрастать новым функционалом. И если вдруг оказывается, что выбранная платформа не позволяет реализовать нужную опцию, приходится всё переделывать на другой платформе/языке/CMS.

Так Excel и Access до сих пор используются, однако они не подходят, когда к учётной системе нужно добавить многопользовательский доступ с разделением прав и веб-интерфейс.
Благодаря тому, что веб-технологии достигли нужного уровня, сейчас можно наблюдать бум развития онлайн конструкторов баз данных и бизнес-приложений, которые позволяют без программирования автоматизировать свои задачи. Потребителями таких продуктов могут быть как организации, имеющие потребность в автоматизации, так и системные интеграторы, которые могут повысить прибыльность бизнеса за счет создания систем для своих контрагентов без дорогих программистов.

Проблема 1: баланс простоты и функциональности

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

Проблема 2: сложный переход с уже используемого решения на конструктор

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

Как может выглядеть идеальное решение

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

Как вариант — с помощью многоступенчатых интерфейсов при создании и настройке приложения:

— Первая ступень: пользователю видны 2-3 основных параметра;
— Вторая ступень: пользователю открывается все дополнительные настройки;
— Третья ступень: открывается возможность написать свой код, если нет нужного функционала.

Пример ступенчатой работы с полями таблицы:

Первая ступень: пользователь задаёт название поля, тип поля и признак уникальности значений.
Вторая ступень: пользователю открывается настройки отображения поля в таблице и форме редактирования, возможность задать обязательность поля в зависимости от состояния записи, группировка полей, настройки переходов в другие таблице при клике по значению в поле.
Третья ступень: возможность самостоятельно на JavaScript описать алгоритм отображения и поведения поля.

Буду рад в комментариях обсудить перспективы конструкторов бизнес-приложений.
Кстати, посмотреть наш сервис можно здесь: getreport.pro

В НОРБИТ мы занимаемся SRM-решениями. Сегодня расскажем про особенный для нашей команды проект — разработку BPMS-платформы NBT. Мы не просто создали бизнес-решение для заказчика, а разработали собственный продукт с нуля, — всё это подразумевает совершенно другой подход к проектированию, разработке, управлению командой, организации процессов доставки изменений и планирования выпусков.

В общем, в статье не только красивая КДПВ. Ещё вы узнаете:

про наш опыт проектирования микросервисной архитектуры (выбор инструментов, подходов к использованию этих инструментов, а именно абстрагирование их использования);
про разработку конструктора бизнес-объектов и внедрение в решение конструктора бизнес-процессов для обеспечения подхода Low-code development;
про то, как мы организовали работу над проектом и избавили разработчиков от некоторых рутинных или отвлекающих их аспектов при работе над системой (абстрактные межсервисные взаимодействия, автогенерация кода, атмосфера в команде);
и про то, какой мем помогал нам в сложные периоды.

Начиная с 2014-2015 годов, ИТ-рынок очень серьезно стал двигаться в сторону импортозамещения, и перед нами достаточно остро встал вопрос развертывания наших систем на операционных системах и СУБД, которые бы подходили под новые требования. По сути это стало вопросом № 1, который нам потребовалось решить, чтобы наши решения могли закрывать требования потенциальных заказчиков в долгосрочной перспективе.

Вопрос № 2, который нам потребовалось решить, состоял в том, что большинство созданных ранее решений предполагали обязательное программирование для добавления атрибутов бизнес-объектов или изменения бизнес-процессов в системе.

Связан он с двумя аспектами.

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

Вопросов и проблем на входе в проект, о котором речь пойдет далее, было гораздо больше. Но эти три (импортозамещение и open-source, Low-code, низкий порог входа и быстрая скорость погружения новых членов команд) мы считаем ключевыми, которые нам предстояло решить.

Проектирование

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

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

На этапе проектирования нам пришлось переосмыслить тот факт, что мы не всегда знаем заранее, кто наш потенциальный заказчик, большой он или маленький, требовательный или лояльный, какие у него бизнес-процессы, какая инфраструктура. Часть требований к будущей системе начали всплывать сами собой: нужно масштабирование, нужна кроссплатформенность, нужна гибкая и быстрая настройка бизнес-объектов/бизнес-процессов, интерфейса, вероятно, «вагон и маленькая тележка» интеграций. Стало страшно, очень страшно.

Наша любимая картинка

Но, как говорит один из наших тимлидов: «Слона нужно есть по кусочкам, начиная с лапки». Мы поставили на этом этапе перед собой две задачи: выбор микросервисной архитектуры и выбор инструментов. Да, именно сразу микросервисной (Мартин Фаулер рекомендует MonolithFirst, но мы его решили ослушаться), потому что с монолитами мы уже давно на «ты» и пришло время принять вызов двигаться дальше. А если серьезно, то одного только требования горизонтального масштабирования системы вполне достаточно, на наш взгляд.

Выбор архитектуры и инструментов

При проектировании архитектуры мы преследовали несколько целей:

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

Frontend решили делать на React + TypeScript, так как он прост в изучении. Мы решили пропагандировать подход full stack разработчиков.

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

Процесс выбора инструментов был тоже достаточно интересным. Нам предстояло решить — какой функционал мы пишем сами, а какой берем «из коробки» (речь о существующих инструментах), но, конечно, абстрагировав всё взаимодействие с ним, чтобы при необходимости была возможность заменить этот инструмент или библиотеку на другую реализацию. Нам были нужны следующие инструменты: поисковый движок, движок бизнес-процессов (BPMN Engine), протокол обнаружения сервисов (Service Discovery), планировщик. Критерии были разные: лицензии, скорость работы, скорость погружения проектной команды и т.д. В результате получился следующий список: Elasticsearch, Camunda, Consul, Hangfire.

Реализация бизнес-идей

К реализации мы подошли с подготовленным списком этапов работ, и самым принципиальным из них был получение в ближайшей перспективе MVP (minimum viable product — минимально жизнеспособный продукт). Мы практически с первых итераций начали работать с акцентом на как можно более быстрое получение прототипа с визуальной частью, которую можно демонстрировать заказчикам (коими вначале были наши руководители) периодически. Этот подход ожидаемо способствовал переосмыслению некоторых задуманных ранее концепций. Удалось выловить несколько противоречий и побороться с ними заблаговременно. Речь идет о проектировании Web API для взаимодействия frontend и backend.

Конструктор бизнес-объектов

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

Рождаемый мышкой конфигуратора бизнес-объект имеет достаточно метаданных, чтобы можно было собирать настраиваемые реестры с поиском и формы с различным представлением.

Создание нового бизнес-объекта (шаблона). Поля бывают разных типов

Заполнение свойств поля. Состав свойств изменяется в зависимости от типа поля

Реестр и фильтр — строятся на основе метаданных, заполненных при создании структуры бизнес-объекта

Реестр событий

Нас не обошел стороной и вопрос валидации бизнес-объектов. Мы быстро обнаружили, что валидация не может не сопровождаться бизнес-логикой, которая требуется на этапе наполнения бизнес-объекта данными. «Если «поле 1» имеет «значение 1», то «поле 2» нужно спрятать» или «Поле 1 является суммой поля 2 и поля 3» — это лишь парочка простейших примеров, которые можно привести. Долго ли коротко ли, и у нас появился движок событий, в котором подобное поведение можно настраивать. События можно тоже настраивать мышкой. Много вариантов уже реализовано, в том числе сложные вычисления. Но это тема отдельного разговора. Напишите, пожалуйста, в комментариях если вы решали подобную задачу, было бы интересно обменяться ощущениями.

Настройка события для поля (это может быть валидация, условие или вычисление)

Конструктор бизнес-процессов

Как мы любим повторять: «Кому нужны бизнес-объекты без бизнес-процессов?». ~~Сказано-сделано.~~ Мы, конечно, знали заранее, что наступит момент, когда нужно будет решать и вопрос бизнес-процессов, и эта задача ~~наводила ужас~~ была чем-то загадочным и мистическим ровно до тех пор, как мы не взялись за нее. Посетив несколько митапов, прочитав и попробовав пару инструментов, мистика развеялась. Было решено использовать движок Camunda (конечно, выполнив все наши процедуры по абстрагированию доступа к этому инструменту). Это замечательный инструмент, который мы всё ещё продолжаем познавать и наращивать варианты его использования.

Текущее положение бизнес-объекта в бизнес-процессе

Результаты

С момента старта проекта прошло полтора года. Команда увеличилась в десять раз, ~~количество седых волос в бороде тоже~~, были решены тысячи задач, проведены сотни daily-митингов, влиты тысячи Pull Request-ов, но похвастаться хочется не этим, а вот чем.

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

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

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

P.S. Сложно в одной статье описать всё детально, поэтому она получилась больше обзорной. Очень надеемся, что вы нашли в ней что-то интересное, и мы с удовольствием ответим на возникшие вопросы в комментариях, или опишем какой-нибудь аспект нашей системы более подробно в отдельной статье.

Вторым важнейшим компонентом приложения СЭД, помимо документов или карточек документов (в модели приложения, реализованной в платформе Docsvision), являются процессы. Если машина состояний, контекстно-ролевая модель и скрипты определяют поведение и логику отдельного документа в системе, то бизнес-процессы предназначены для реализации сложных сценариев маршрутизации, взаимодействия с внешними по отношению к СЭД приложениями, для обработки событий, не связанных с активностью пользователей, и другой серверной активности в отношении документов.
Например, БП может автоматически создавать новые документы в случае необходимости, обеспечивать передачу информации между документами при возникновении тех или иных событий, рассылать уведомления и т.д.

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

Отмеченная мною выше особенность – совмещение задач моделирования и имплементации в одном инструменте приводит к тому, что для описания процесса используется специальная нотация, ориентированная на конкретную среду исполнения и ее особенности.
С одной стороны, язык описания процесса (нотация) должен содержать элементы, которые представляют логику процесса на высоком уровне – функции для обозначения активностей пользователя и системы, логику последовательности обработки — ветвления и объединения, а также средства декомпозиции процесса (подпроцессы для организации иерархического моделирования).
С другой стороны, необходимы стандартные компоненты, которые позволяют описывать алгоритм обработки, реализовывать в процессе конструкций типа (if – then – else, do-while) работу со счетчиками, коллекциями, операторы сравнения и пр. Также необходимы низкоуровневые функции, ориентированные на работу с конкретными бизнес объектами и их данными, функции обработки специфических для системы событий, управление синхронизацией процесса.
Дополнительно необходимы инструменты для программного расширения стандартного набора функций и функции для реализации сценариев интеграции с другими приложениями.
Все это приводит к тому, что каждая реализация реальной промышленной Workflow системы и Docsvision, в частности, реализует собственную нотацию, которая может использоваться как для моделирования (визуального представления процесса для человека), так и программирования (низкоуровневого описания). При этом модель описания процессов Docsvision содержит все конструкции нотации BPMN (визуально с ней не совпадая), что позволяет импортировать в Docsvision процессы, смоделированные на языке BPMN для дальнейшей имплементации.

Рис. 1. Дизайнер процессов Docsvision реализует собственную нотацию, ориентированную на создание работоспособных приложений, реализующих логику обработки документов в приложениях.

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

Для описания (программирования) процессов Docsvision используется шаблоны. Помимо функций и связей шаблоны содержат параметры.
Параметры — это внутренние переменные процесса, используемые для хранения информации конкретного экземпляра процесса. Например, в процессе обработки договора переменные – это сам файл документа, сумма договора, имя ответственного и согласующих лиц, сроки согласования, контрагент, вид услуги или продукции и пр. Переменные процесса используются для двух целей.
• Первая очевидна – для определения логики обработки процесса и передачи информации между функциями. Например, при старте обработки процесс получает на вход файл договора, который передается между участниками в процессе согласования, а сумма договора используется в функциях условного ветвления для определения логики согласования договора – формы финансового контроля.
• Вторая функция переменных менее очевидна – это параметризация исполняемых функций. Шаблон процесса может содержать функции, которые не содержат конкретных значений параметров (например, имени исполнителя задачи, или срока выполнения). Эти параметры функций могут определяться (или даже вычисляться) по ходу выполнения процесса и на предыдущих шагах, и передаваться в функцию в момент ее инициализации. Это позволяет моделировать сложные процессы, адаптируемые к обрабатываемой в них информации и существенно сокращать количество шаблонов. Если бы данная функция отсутствовала, для каждого частного случая потребовался бы отдельный шаблон, что сильно усложнило бы сопровождение приложений.

Процесс может быть запущен вручную, из другого процесса или с использованием программного интерфейса (API).

Конструктор бизнес-процессов поддерживает работу со следующими видами переменных. К простым относятся следующие типы переменных:
• целое;
• дробное;
• строка;
• да/нет;
• дата/время;
• строковые перечисления.

Большинство переменных позволяет обрабатывать в процессе различные сущности платформы Docsvision:
• карточка;
• файл;
• секция карточки;
• строка секции карточки;
• папка;
• ярлык;
• подразделение: выбирается из справочника сотрудников;
• сотрудник: выбирается из справочника сотрудников;
• группа: выбирается из справочника сотрудников;
• роль: выбирается из справочника сотрудников;
• тип карточки;
• перечисление;
• процесс;
• переменная процесса;
• значение переменной процесса;

2 шлюза — шлюз к файловой системе (ФС) и шлюз к электронной почте входят в конструктор процессов по умолчанию, они несут с собой следующие переменные:

Рис.2. При настройке переменных можно указать ее тип, значение по умолчанию и другие свойства параметра.

Переменные в процесс передаются одним из следующих способов:
• Они могут быть заданы по умолчанию;
• Вводятся вручную при старте процесса;
• Переданы в подпроцесс при автоматическом запуске из родительского процесса;
• Сформированы в ходе процесса, в частности, с помощью скриптов;
• Получены из обрабатываемых процессом документов и других объектов;
• Сформированы автоматически при выполнении операции запуска процесса из интерфейса работы с конкретным документом, если процесс запускается бизнес логикой обработки документа;
• И, наконец, переданы в процесс программно с использований функций API, если процесс стартует с помощью программного кода.

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

Процесс состоит из функций.
Первая группа функций позволяет описать общую структуру процесса – это функции:

Старт – точка начала процесса;
Cтоп – остановка процесса;
Разветвление – создание параллельных веток процесса;
Объединение по И и по ИЛИ – объединение веток процесса;
Подпроцесс – функция служит для декомпозиции процесса при моделировании. Она запускает определенный шаблон и передает туда переменные из родительского процесса. Подпроцесс может быть синхронным, тогда родительский процесс ждет его окончания и получает обратно переменные, и асинхронным – родительский процесс просто запускает подпроцесс. Этот способ запуска процессов используется, в частности, для обработки различных событий. Например, родительский процесс ожидает появления новых документов в системе и запускает параллельные процессы по их обработке.

Вторая группа функций позволяет расширять логику обработки процесса:

Рис.3. Функция сценарий позволяет расширять поведение системы и реализовать произвольную обработку в рамках процесса.

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

Универсальная функция – еще одна очень важная функция, которая используется для выполнения операций с объектами и переменными без программирования. Функции реализуются как сервисом бизнес-процессов для стандартных объектов Docsvision, так и компонентами шлюзов для внешних по отношению к Docsvision системам. При настройке функции определяется, в отношении какого типа объекта будет реализовываться действие, с помощью переменных процесса определяется указатель на объект и другие параметры функции. В системе есть несколько десятков поддерживаемых типов объектов и соответственно сотни функций по их обработке. В статье нет смысла их подробно рассматривать, в качестве примера приведу только список функций, доступных для обработки объекта типа бизнес-процесс.

Функции	Параметры функции	Тип значения параметра
Создать экземпляр процесса	Название экземпляра Шаблон процесса Папка Запустить процесс Возвращаемое значение	Строковое Карточка DV Папка DV Да/Нет Процесс DV, выходной параметр
Запустить процесс	—	—
Остановить процесс	—	—
Получить переменную процесса по имени	Имя переменной Возвращаемое значение	Строковое Переменная процесса DV, выходной параметр
Приостановить процесс	—	—
Создать переменную	Имя переменной Идентификатор шлюза Тип переменной в шлюзе Коллекционная переменная Возвращаемое значение	Строковое Строковое Целое Да/Нет Переменная процесса DV, выходной параметр

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

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

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

Читайте также: