Для чего нужна процессная модель
Зачем нужна модель бизнес-процесса?
Нас часто забывают спрашивать, почему мы так любим бизнес-процессы и какие задачи мы решаем с помощью процессного управления. В этой пилотной статье нашего блога рассмотрим, как с помощью одной модели одного бизнес-процесса можно решить несколько практических задач из жизни бизнеса любого размера.
Организационно-штатная структура
Давайте для примера создадим если не федеральный банк, то хотя бы отдел продаж новой компании для плановой продажи N единиц продукта в месяц. Для отдела нужны сотрудники и начальник. Сколько и каких сотрудников и начальников надо для продажи такого объема продукции? Пока не ясно, придется набросать модель. До появления BPM-сервиса «БП Симулятор» это приходилось делать на пляжном песке, на стенах и других доступных платформах.
Формирование бизнес-требований для внедрения ПО
Мы подготовили ресурсы, необходимо подумать об инструменте — программном обеспечении. Проектный менеджер из ИТ-отдела будет рад, если вместо серии противоречивых интервью вы дадите ему более подробную модель будущего бизнес-процесса. Так вот-же она, мы добавили входы/выходы и ресурсы для выполнения функций:
Операционные расходы
С капитальными расходами на лицензии ПО определились, а что с операционными? Надо провести стоимостной анализ доли затрат на себестоимость продукта. Дополним нашу модель стоимостью ресурсов (или свяжем созданную ранее организационную модель с данными из ПО по начислению заработной платы).
Так просто? Теперь да, а вот раньше для проведения такого анализа необходимо было привлечь операционистов, продуктологов, технологов, финансистов и кадровиков. Если в процессе создания драйвера расходов сам процесс изменялся, то приходилось весь расчет начинать сначала.
Регламент выполнения
Казалось-бы, что может быть проще для формирование регламента выполнения бизнес-процесса дать задание тетушке в пуховом платке (методолог), объяснить, помолиться и подождать несколько месяцев до появления в муках рожденного Регламента. Может, если помнить, что и модель и регламент — это разные формы одной сущности. Берем нашу модель и пальчиком или курсором сверху вниз:
Ежедневно при получении документа «Список клиентов для обзвона» Персональный менеджер выполняет функцию «Привлечение клиентов» согласно нормо-регулирующего документа «Инструкция по обзвону» с помощью программного средства «CRM». В результате выполнения функции должен быть заполнен документ «Результат звонка». Нормативное время выполнения функции «Привлечение клиента» составляет 00:30:00.
Если в результате выполнения функции «Привлечение клиентов» произошло событие «Клиент принял предложение»… и т.д.
Все, актуальный и полный регламент, понятный и для исполнителя и для контролера готов, несите на подпись.
Проведение экспериментов
Эксперименты в боевых условиях очень дорого обходятся. Как узнать, как будет себя вести процесс, если в пятницу сделать рабочий день короче, в среду неожиданно уйдет в декрет главный специалист и сколько физически смогут продать цветочники 8 марта? Для этого надо модель нашего процесса поместить в имитационную среду, максимально приближенную к реальной.
Кроме модели бизнес-процесса понадобится модель внешней среды, но это просто необходимо знать, как часто запускается экземпляр процесса и события, влияющие на его выполнение. Например, днем в колл-центр входящий звонок поступает в среднем каждые 5 минут.
Симулятор будет запускать задачи в модель бизнес-процесса в том количестве и так долго, сколько необходимо. А по завершению у вас останутся результаты имитационного моделирования, необходимые для принятия решения, как будто процесс реально проработал нужное время.
В отличие от статичной модели, в результатах симуляции видно, что сотрудники не работают более 8 часов, их задачи переносятся и ждут своей очереди на выполнение или доступных ресурсов, приближая расчетные данные производительности к фактическим.
Заключение
Все описанные выше примеры применения модели реальны, часто применимы и доступны. Кроме этого, при помощи модели БП просто решаются и менее тривиальные задачи: составление карты рисков, анализ контуров управления качеством и источников дефектов для бережливого производства. Имея модель всего одного процесса для формирования перечисленных результатов экономится очень много человеко-часов, в случае изменения процесса так же легко, путем внесения изменений в модель актуализируются и результаты. Нам лень тратить время на рутину, вот почему мы любим процессы и, надеемся, полюбите и вы.
Моделирование бизнес-процессов для стартапа: что это такое и для чего нужно
Стартап — проект, который по определению призван быть уникальным. Это поиск нового решения для проблемы пользователя, создание некоего инновационного продукта, которого пока нет на рынке. Наверное, кажется кощунством в этом ключе говорить о таких вещах, как планирование, создание регламентов и написание инструкций, моделировании бизнес-процессов. Тем не менее, без них, а в особенности без последнего, вашему стартапу будет сложно добиться успеха. Рано или поздно вы столкнетесь с тем, что не знаете сферу ответственности каждого из членов команды, потому что все занимаются по чуть-чуть всем; с некоторым хаосом в задачах, снижением эффективности работы и прочими прелестями “творческого процесса”. В этой статье я расскажу, что такое бизнес-процессы, как их моделировать и как это поможет сделать работу стартапа слаженной и продуктивной.
Бизнес-процессы — взаимосвязанные мероприятия, или работы, цель которых — создание продукта или услуги. Все бизнес-процессы подразделяются на три больших вида в зависимости от назначения:
К примеру, ваш стартап — это сеть фитнес-центров с консультирующими диетологами и мобильное приложение, которое позволяет клиентам записываться на консультации со специалистами, бронировать и оплачивать занятия с учетом удобного для себя времени, направления, района. В таком случае управляющими процессами здесь будут изучение рынков соседних городов на предмет открытия там спортзалов, переговоры с местными властями о предоставлении помещений на выгодных для вас условиях. Операционные процессы — работа спортзалов по установленному расписанию, организация индивидуальных встреч клиентов с диетологами, создание для них индивидуальных планов диет и физических нагрузок, продвижение бренда. Вспомогательные процессы — поиск диетологов и фитнес-тренеров в команду, ведение бухучета, поддержание работы сайта и мобильного приложения.
Моделирование бизнес-процесса — это построение модели-представления, которая отражает самые важные черты и свойства исходного процесса. Простыми словами, вы прописываете, как все должно выглядеть в идеале.
Чтобы создать модель, необходимо определить:
В нашем стартапе результатом бизнес-процесса по привлечению клиентов является запись клиента на очную платную консультацию с диетологом через мобильное приложение. Действия выполняются клиентом, который установил приложение и оставил через него заявку, а также администратором, который обрабатывает все поступающие заявки и уточняет у клиента, придет ли он в указанное время на встречу.
Что касается документов, то с точки зрения бизнес-процессов под ними понимается любая информация на любом носителе. В нашем случае это информация на экранах мобильного приложения с презентацией нашего продукта, опросом клиента с целью выявления его проблемы, календарь и карта, при помощи которых клиент выбирает удобное для него время и место консультации/занятий. Далее, когда заявка поступает администратору, он, созваниваясь с клиентом, пользуется заранее подготовленными скриптами, которые также в данном случае являются документами.
Надежность процесса гарантируется автоматизированной работой приложения, а также работой администратора, который отслеживает все возможные нестыковки и сбои в ПО.
Расширение процесса в будущем у нас также предусмотрено: мобильное приложение дает возможность клиенту после консультации с диетологом самому выбирать время и место занятий, бронировать их и оплачивать через приложение уже без контакта с администратором.
Кейс 1. Идеально отлаженный бизнес-процесс: Википедия
Все мы знаем и регулярно пользуемся продуктом этого проекта — свободной энциклопедией. Это пятый по посещаемости сайт в мире, на котором размещено десятки миллионов статей на 300 языках, писать статьи и вносить правки может любой желающий, т.е. гипотетически “работать” в Википедии может любой житель планеты, у которого есть доступ в интернет.
Парадоксально, но в фонде Викимедиа, который занимается техподдержкой и управлением Википедии, работает около 300 человек. Гигантский проект двигают четко отлаженные бизнес-процессы с максимальной автоматизацией и использованием искусственного интеллекта.
Каким бы скучным это ни казалось, однако в самом начале активной фазы развития стартапа следует уделить несколько дней описанию процессов, которые протекают на вашем, пускай еще совсем маленьком предприятии. Это поможет избежать ряда неудобств и проблем как в настоящее время, так и в более отдаленном будущем, когда проект станет более масштабным. Итак, каких же проблем поможет избежать моделирование бизнес-процессов?
1. Неопределенности, как поступить на том или ином этапе развития компании. К примеру, уволился один из ключевых сотрудников, который был на проекте с самого начала, теперь неясно, как именно строилась его работа, т.к. компания видела результаты, и они были положительными. Руководство не видело необходимости вмешиваться в работу человека. В итоге теперь нет представления, как ввести в курс дела новичка.
Если все процессы на вашем проекте прописаны, то вы избежите вышеперечисленных неудобств: вы заранее будете знать, куда и как будет поставляться ваш продукт и кто будет контролировать это; вы будете знать, как выстроена работа каждого из ваших сотрудников, а все их деловые контакты, связи будут задокументированы.
2. Саботажа со стороны сотрудников, когда компания уже на более поздних этапах решится регламентировать их деятельность. Люди будут считать, что их интересы, свободы грубо ущемлены, т.к. изначально речи об инструкциях, регламентах, описаниях рабочих процессов не было.
3. Хаоса в команде, когда, к примеру, у сотрудников есть должности, но нет полномочий, или когда над одним и тем же процессом параллельно работает несколько человек, в результате работа дублируется, в то время как другие задачи простаивают.
4. Снижения эффективности стартапа и его акционерной ценности (shareholder equity). Моделирование бизнес-процессов позволяет собственникам сконцентрироваться на собственной прибыли предприятия, детально контролировать доходы и расходы. Предприятие за счет привлеченных средств (кредиты, инвестиции, дотации), может казаться какое-то время безубыточным, однако на самом деле его акционерная стоимость в этом случае невелика.
5. Потери клиентов. Хорошо налаженные бизнес-процессы позволяют команде работать эффективно и быстро, а это существенный фактор в наши дни. Если сравнить бизнес-среду с фудкортом, то компании с хорошо отлаженными процессами — это точки, где клиентов обслуживают без промедления, они платят за свой заказ и уходят довольные. А вот компании, у которых бизнес-процессы не отлажены, часто теряют клиентов, т.к. из-за внутренней неразберихи менеджеры не успевают уделить внимание всем заявкам, в итоге многие заказы уходят.
6. Ряда непродуманных/неконтролируемых расходов. Моделирование делает работу каждого человека в компании прозрачной: известно, сколько составляет его зарплата, при каких условиях он получает премию, сколько составляют расходы на командировки, где и по какой цене закупаются канцтовары. Когда все процессы прописаны, практически исключается возможность какого-либо сокрытия денег, их хищения — как мелкого, так и крупного.
7. Конфликтов в команде. Рабочие конфликты возникают чаще всего там, где управление не формализовано и не регламентировано. Благодаря моделированию бизнес-процессов, обязанности и полномочия каждого сотрудника детально прописаны, руководители в курсе, как выстроены все процессы в их сфере ответственности и могут детально объяснить это подчиненным. Каждый менеджер точно знает, что должен делать тот или иной сотрудник.
Моделирование бизнес процессов
Моделирование бизнес процессов является одним из методов улучшения качества и эффективности работы организации. В основе этого метода лежит описание процесса через различные элементы (действия, данные, события, материалы и пр.) присущие процессу. Как правило, моделирование бизнес процессов описывает логическую взаимосвязь всех элементов процесса от его начала до завершения в рамках организации. В более сложных ситуациях моделирование может включать в себя внешние по отношению к организации процессы или системы.
Моделирование бизнес процессов позволяет понять работу и провести анализ организации. Это достигается за счет того, что модели могут быть составлены по различным аспектам и уровням управления. В больших организациях моделирование бизнес процессов выполняется более подробно и многограннее, чем в малых, что связано с большим количеством кросс-функциональных связей.
Обычно для моделирования бизнес процессов применяются различные компьютерные средства и программное обеспечение. Это облегчает управление моделями, отслеживание в них изменений и позволяет сократить время анализа.
Цели моделирования бизнес процессов
Конечная цель моделирования бизнес процессов заключается в том, чтобы добиться улучшения работы. Для этого в ходе анализа основное внимание уделяется повышению ценности результатов процесса и снижению стоимости и времени выполнения действий.
Моделирование бизнес процессов преследует несколько целей:
Стадии моделирования бизнес процессов
Моделирование бизнес процессов, как правило, включает в себя выполнение нескольких последовательных стадий. Т.к. конечной целью моделирования является улучшение процессов, то оно охватывает и «проектную» часть работы, и работы по внедрению моделей процессов.
Состав стадий, которые включает в себя моделирование бизнес процессов следующий:
Виды моделирования бизнес процессов
Моделирование бизнес процессов может иметь различную направленность. Это зависит от того, какие проблемы предполагается решить с его помощью. Учет абсолютно всех воздействий на процесс может значительно усложнить модель и привести к избыточности описания процесса. Чтобы этого избежать, моделирование бизнес процессов разделяют по видам. Вид моделирования выбирается в зависимости от исследуемых характеристик процесса.
Для целей совершенствования процесса применяют следующие виды моделирования:
Разделение моделирования по видам выполняется для упрощения работы и концентрации внимания на тех или иных характеристиках процесса. При этом для одного и того же процесса могут быть применены различные виды моделирования. Это позволяет работать с одним видом моделей независимо от других.
Принципы моделирования бизнес процессов
Моделирование бизнес процессов основывается на ряде принципов, которые дают возможность создать адекватные модели процессов. Их соблюдение позволяет описать множество параметров состояния процессов таким образом, чтобы внутри одной модели компоненты были тесно взаимосвязаны, в то время как отдельные модели оставались в достаточной степени независимыми друг от друга.
Главными принципами моделирования бизнес процессов являются следующие:
Методы моделирования бизнес процессов
На сегодняшний день существует достаточно большое количество методов моделирования бизнес процессов. Эти методы относятся к разным видам моделирования и позволяют сфокусировать внимание на различных аспектах. Они содержат как графические, так и текстовые средства, за счет которых можно наглядно представить основные компоненты процесса и дать точные определения параметров и связей элементов.
Моделирование бизнес-процессов выполняют с помощью следующих методов:
Большинство из указанных методов реализованы в виде программного обеспечения. Оно позволяет осуществлять поддержку бизнес-процессов или проводить их анализ. Примерами такого ПО являются различные CASE средства моделирования процессов.
Моделирование бизнес-процессов, автоматический перевод «диаграмма-текст» и CH-1 нотация
По роду своей деятельности мне довольно приходилось довольно много моделировать бизнес-процессы различных организаций. Как уже работающих компаний (с целью систематизации и оптимизации существующей деятельности), так и новых, т.е. старт-апов (проектирование деятельности «с нуля»). В этой заметке я попробую кратко обобщить цели такого моделирования (раздел I), основные виды моделей (раздел II), рассказать о своих инструментальных наработках (раздел III), а также порассуждать о том, чего тут еще не хватает, в т.ч. и с точки зрения курса на импортозамещение (раздел IV).
(I) Что это и Зачем все это нужно
Действительно, первый и естественный вопрос – а что это такое и зачем вообще это нужно на предприятии? Пойдем и мы каноническим путем и начнем прямо с начала (Ваш К.О.). Итак:
(1) Бизнес-процессы предприятия – это просто совокупность всех его внутренних процессов, т.е., аллегорически, это – «физиология предприятия» (в то время как организационная структура – это его «анатомия»). Чтобы чем-то управлять – нужно, как минимум, знать, как оно работает.
Важно понимать, что любой бизнес-процесс (т.е. деловой процесс) – это просто некоторая технология работы, которая или уже фактически существует в организации, или же предполагается к осуществлению (проектируется), но никак не какой-то документ или «листик с квадратиками и стрелочками». Нет, любой процесс – это технология, порядок выполнения каких-либо действий, необходимых для бизнеса (для организации). Более того, не будем забывать, что в идеале такой порядок работы должен определяться внутренними документами на официальном языке – стандартами организации (СТО). А сами графические схемы являются удобным средством проектирования нового порядка работы / визуализации уже существующего (и их можно оформлять в качестве информационно-справочного приложения к СТО).
(2) Наличие актуальной и подробной процессной модели работы (в виде комплекта актуальных СТО и/ или иерархического набора графических диаграмм) уже работающего предприятия значительно упрощает:
(5) Использование графических диаграмм процессов облегчает обучение новых сотрудников и их адаптацию, а также позволяет уйти от излишней зависимости от «ноу-хау» отдельных сотрудников («Если он уйдет – как же во всем этом разобраться»?),
(6) Наличие формализованных описаний внутренних процессов является важной вехой на пути внедрения информационных систем и средств автоматизации деятельности.
Примечание. Здесь важно не путать первичное и вторичное. Да, компьютерная программа может работать только по четкому алгоритму. Но не нужно забывать, что «Автоматизация для бизнеса, а не бизнес для автоматизации», и что множество бизнес-процессов предприятия всегда больше (уж точно не меньше) области автоматизации. Итак, сначала ноты (технология) – потом инструмент (автоматизация), но не наоборот.
(7) Региональная экспансия: «записав» в модель/ систему внутренних стандартов технологию работы успешного предприятия, можно затем ее тиражировать на другие, вновь открываемые, или создать франшизу.
(II) Модели процессов: виды
(II.1) С точки зрения актуальности содержания модели делятся на:
(1) Модель «Как есть» (англ. «AS IS»): отражает РЕАЛЬНОЕ положение дел на момент описания, фактически имеющуюся, сложившуюся технологию работы.
(2) Модель «Как должно быть» (англ. «TO BE»): отражает целевое состояние, которое в дальнейшем предполагается претворить в жизнь. Например, модель работы вновь открываемого предприятия, или же новый (совсем новый или улучшенный старый) порядок выполнения каких-либо работ.
(2) Модель «Как должно бы быть» (англ. «SHOULD BE»): отражает «идеализированное» положение дел (согласно регламентирующим документам), тогда как фактическая схема работ в реальности может быть несколько иной. На практике необходимость в построении таких моделей встречается нечасто.
Отметим, что приведенные модели одного и того же процесса могут различаться весьма значительно. Пример: модель регулируемого пешеходного перехода, светофор переключается автоматически через определенный промежуток времени.
«Как есть»: Некоторые пешеходы ждут зеленого и переходят только на зеленый. А некоторые – не ждут зеленого сигнала, они смотрят по сторонам и перебегают дорогу, если, по их мнению, опасность попасть в ДТП им не грозит. Так делать не стоит, но в реальности, к сожалению, случается.
«Как должно бы быть» (ибо так написано в ПДД): Все пешеходы ждут зеленого и переходят только на зеленый.
В данном случае, модель «Как должно бы быть» могла бы совпасть с «Как должно быть». Однако они могут не совпасть, если в качестве модели «Как должно быть», т.е. той, которая будет признана целевой, будет одна из следующих:
«Как должно быть»: «Светофор с кнопкой». Пешеходы подходят к переходу и нажимают на кнопку – через определенный промежуток времени загорается зеленый.
«Как должно быть»: Пешеходный переход запрещен.
«Как должно быть»: Пешеходный переход станет надземным или подземным.
«Как должно быть»: Улица станет пешеходной.
(II.1) С точки зрения метода моделирования и, соответственно, области применения результата рассмотрим следующие виды моделей:
(1) Функциональные модели.
(2) Модели потоков работ (worklow-модели).
Функциональные модели представляют собой «принципиальную схему работы». Т.е. что рожь сначала сеять, потом жать, потом молотить. Или что сначала изготовить детали, потом собрать изделие, потом – выходной контроль качества. И т.д.
Сегодня, пожалуй, одной из самых популярных методологий функционального моделирования является IDEF0. По сути, эта методология является де-факто «мировым стандартом», признанным как за рубежом, так и в РФ (см., напр. Р 50.1.028-2001. методология функционального моделирования). Описание методологии IDEF0 легко найти, в т.ч. и в Сети.
Моделирование предприятия часто рекомендуют начинать с формирования функциональной модели. Однако нужно помнить, что такие модели являются «статичными», они не предназначены для, например, описания пошаговой реализацию какой-либо рабочей процедуры. А предназначены они для отображения общей картины, принципиальной схемы работы. Что до детальных пошаговых моделей осуществления какой-либо деятельности, то для этого предназначены модели потоков работ (worklow-модели). И о них – ниже.
Модели потоков работ (worklow-модели) позволяют описать процесс как упорядоченную последовательность выполнения различных действий, возникающих событий, а также объектов, участвующих в реализации данного процесса. Именно такие модели нужно строить, когда Вы хотите описать/ спроектировать конкретный процесс на своем предприятии, например, «Порядок приема товара на склад», «Правила подачи заявки на перевозку», и др.
Модели потоков работ могут формироваться как на очередном шаге построения функциональной модели – при ее дальнейшей детализации, – так и самостоятельно, когда есть необходимость описать (спроектировать) какую-либо отдельную процедуру. На практике второй путь тоже используется нередко, когда работа начинается с «болевых точек» предприятия, или же вообще идет методом «от реестра процессов предприятия».
Что до выбора конкретной нотации worklow-моделирования (т.е. собственно графического языка), то тут, в отличие от функционального моделирования, выбор довольно большой. Это и IDEF3, и «плавательные дорожки», и средства ARIS, и методология BPMN, и другие. И каждой из этих методологий есть свои плюсы.
Что до меня, то я пользуюсь нотацией «собственного изготовления» – CH-1 нотацией. Скажу честно, когда я только начинал заниматься выстраиванием бизнес-процессов, у меня и в мыслях не было сочинять какой-то там язык. Но: начав с одного из стандартных средств, в реальной работе оказалось (повторюсь, именно в моем случае), что средств используемого языка недостаточно для краткой и полной записи «со слов», причем без потери данных, другой оказался для сотрудников слишком сложен…. И вот так, вводя дополнительные символы и некоторые изменения, не думая – не гадая, в середине «двухтысячных» и появилась CH-1. Пара слов о ней ниже.
(III) Пара слов о CH-1 нотации
Итак, нотаций workflow-моделирования существует множество. И это нужно рассматривать как плюс: принцип «пусть расцветают сто цветов» тут как нельзя более кстати. Выбор нотации моделирования зависит от задачи (а задачи бывают очень разные). Например, для моделирования производственных линий используются совсем другие, не упомянутые здесь методы моделирования. Так что такой «методический плюрализм» в моделировании потоков работ не случаен.
Если мы говорим о CH-1 нотации, то она изначально предназначена для описания процессов в виде последовательности действий с указанием их исполнителей, связанных событий, значимых параметров выполняемых действий и/ или процесса в целом (например, нормативная длительность) и возникающих потоков: материальных и информационных. Русскоязычная версия ее спецификации (с примерами) выложена здесь: https://drive.google.com/open?id=0B_wUAIgOErG8MTQzYzJhNGUtZGY1NC00OTE1LWFlMzgtMDEyZmFjYTFjMDk3, подробнее см. также здесь https://ch1-notation.blogspot.com (персональная страница про CH-1).
Если же говорить о софте, то используемые в данной (как, впрочем, и в любой другой) нотации символы можно найти почти в любом ПО, имеющем встроенные библиотеки графических примитивов. Причем как в коммерческом ПО, так и в ПО, распространяемом бесплатно. Кроме того, на сегодняшний день в ряде программных продуктов существуют специальные библиотеки символов CH-1.
При этом, если используемый программный продукт поддерживает механизм гиперссылок (что встречается довольно часто), то с их помощью полезно:
(IV) В мечтах о будущем: автоматическая генерация регламентов (машинный перевод «диаграмма-текст»)
Диаграмма (схема) бизнес-процесса – это, по сути, его (прото)регламент в графическом виде. Ну, или (прото)стандарт организации, если выражаться более официально. Вся информация о том, «кто, куда, чего и как» должна там наличествовать. А, соответственно, встает вопрос: «Нельзя ли сформировать текст по диаграмме нажатием одной кнопки»? Причем задачу можно усложнить: регламент (стандарт) должен быть на «человеческом» языке, а не в стиле «отчет» из серии набора заголовков: «Кто?» «Что?» «Когда?» и т.п. и автоматически копируемого в соответствующие разделы несклоняемого текста.
Если говорить о CH-1 диаграммах, то для них был разработан алгоритм их машинного перевода на «человеческий язык» в форму готового проекта стандарта. Алгоритм – на сей день не оттестированный (ввиду нереализованности в коде) – размещен здесь: https://drive.google.com/open?id=0B_wUAIgOErG8bTluc2xYSVI4NXc, см. также здесь: https://ch1-notation.blogspot.com (персональная страница про CH-1). С реализацией этого в коде одному мне не справиться не удалось. При этом оптимальным видится двуступенчатый вариант, когда мы имеем экспорт из графического редактора в, например, xml, а затем генерацию текста в текстовом редакторе уже из xml. Подобная организация является открытой в том смысле, что последовательно к ней можно «подрубать» все новые и новые графические и текстовые редакторы. Также она должна обеспечивать конфиденциальность данных, и, с этой точки зрения, вариант ПО с открытым исходным кодом является выигрышным.
И в заключении – о чем? – об импортозамещении. Совершенно очевидно, что, как минимум, для стратегических предприятий, госорганов и других организаций, для которых важна информационная безопасность, доверять даже «отрисовку» своих процессов импортному ПО с закрытым исходным кодом может быть неприемлемым. Действительно, процессная модель предприятия, охватывающая его внутренние процессы, – что в графическом (иерархический набор диаграмм), что в текстовом (в виде стандартов организации) виде, – содержит почти всю информацию о его внутреннем устройстве – «бери и строй», как говорится. Поэтому создание подобного полностью отечественного программного продукта (как синтез «рисовалки» (редактор диаграмм, графический векторный редактор) и «текстогенератора») приобретает особую актуальность.