Автоматизация бизнес-процессов — проект MantiSERP

MantisSERP. Это система для простой автоматизации бизнес-процессов компании. При управлению любым проектом и даже самим собой, стоит использовать какой-нибудь трекер задач, ибо количество задач всегда превышает возможности на текущий момент. На протяжении 5 лет я использую MantisBT для решения подобной задачи. Ничего лучше найдено не было, к сожалению.

MantisSERP — Mantis Simple ERP. Почему Mantis? Потому что существует такой прекрасный bug tracker «MantisBT». В основе ManrisSERP лежит идея простоты и топорности Mantis с точки зрения интерфейса, при чем образца ветки 1.2.х. Именно поэтому я считаю, что слово Mantis в названии обязательно, это источник вдохновения. Почему Simple ERP? Потому что куда не глянь везде стоимость ERP-шок зашкаливает и все они написаны на Java в виде приложения на компе. Так как моя ERP-шка решает одну сравнительно небольшую, но одну из самых важных задач в бизнесе — управление базовыми бизнес-процессами, поэтому она достойна называться ERP, но сама по себе Simple.

Если совсем по научному выражаться, я делаю что-то вроде https://en.wikipedia.org/wiki/Workflow_management_system. По этому вопросу есть даже целые промышленные стандарты, но я не вдавался в подробности. Да и вообще, как-то все равно на эти стандарты, если нет готового удобного прикладного решения, кроме MantisBT который вообще не для этого придуман с архитектурной точки зрения, хотя с интерфейсной точки зрения практически идеал.

Наш путь будет следующий

1. Анализ проблемы
2. Проблему поняли какой подход?
3. Перейдем к конкретике. Что должно быть в системе?
   1. Бизнес-процесс — единственный универсальный объект системы
   2. Исполнители процесса — древовидные права доступа к процессу
   3. Конфигурация процесса — состояния задачи, права на изменения состояния
   4. Дедлайн процесса
   5. Понятие конечной задачи как частный случай процесса
   6. Зависимость задач друг от друга, построение цепочек задач
   7. Очереди и автоматизация
4. Выводы
5. Реализация

1. Анализ проблемы

Лично я за много лет понял одно. Я не мыслю какое-либо управление без системы учета. Как ты можешь эффективно руководить даже своим товарищем по работе, если порой у себя бывают проблемы с организацией. Ладно, бумагу мы уже не используем, да сохранят цифровые технологии бедных зверюшек. Но в худшем случае это блокнот (Noteoad++), в среднем может быть какой-то туду, в общем мясорубка из всего и всегда каждый день приходится решать что делать, а что нет. А когда дела касается анализа ДАЖЕ своего KPI, то все о чем я сказал накрывается окончательно медным тазом. А если 2 человека, 2 блокнота онлайн через гуглодоки… Пфффф…

2. Проблему поняли какой подход?

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

3. Перейдем к конкретике. Что должно быть в системе?

Во первых. Я начал с того что MantisBT действительно тянет для этих задач. Это так, в нем есть все что нужно. Есть конфигурация всего одного бизнес-процесса. Есть возможность разделять трекеры задач (ака отделы — бухгалтерия, тех поддержка, разработка). Есть возможность категоризировать задачи внутри одного трекера. Все юзабельно, но все же это баг трекер и им должен оставаться.

3.1. Бизнес-процесс — единственный универсальный объект системы

А если подумать масштабнее, давайте начнем абстрагировать. Зададимся вопросом, что такое задача, и чем общая «задача компании», записанная прямо в уставе и прописанная в законе РФ и других стран — «приносить прибыль», отличается от задачи рядового копирайтера, которому менеджер N-го уровня относительно учредителей поручил задачу написать текст на сайт или менеджеру по закупкам закупить технику? Ответ простой. Ничем. Это единый универсальный объект который зовется процессом, а точнее «бизнес-процессом». Разберем пример работы с этим универсальным бизнес-процессом.

• Когда учредители принимают решение открыть компанию, автоматически хочешь ли ты или не хочешь начинается корневой бизнес-процесс «компания».
• Возникают некоторое количество подпроцессов — первичных задач, например:
  • организация компании (юридический отдел);
  • организация финансов (финансовый отдел);
  • организация разработки ПО (отдел ПО);
  • организации отдела монетизации (продажи);
• После того как созданы процессы отделов, начинаются работы внутри этих отеделов, например разработка ПО делится на другие подотделы (подпроцессы), которые в добротных компаниях не должны быть связаны
  • Отдел разработки
  • Отдел тестирования
  • Отдел сопровождения
• Не будем дробить отдел разработки, посчитаем, что у нас монопродуктовая компания, но в реальности дробить можно до бесконечности!!! Так как по сути мы оперируем одним и тем же объектом «Процесс». Следовательно в этом отделе могут создаваться ЕЩЕ процессы =), которые уже исполняют конечные исполнители, латая дыры в коде, создавая новые фичи и прочее. Вот тебе и Mantis просто немного абстрагированный.

Интересно, что даже если это все один человек-оркестр, и он не осознает происходящее с ним, то все равно формально его работа дробится на множество подотделов, которые со временем все равно придется выделять из себя =). Так что это применимо к одному человеку так и к 100 тысячам человек.

3.2. Исполнители процесса — древовидные права доступа к процессу

Любой процесс должен быть кем-то исполнен. Поэтому у каждого процесса должен быть «инициатор» и «ответственный», так же могут быть те кто «отслеживают». Ответственный может видеть процесс, создавать подпроцессы и назначать ответственных этому подпроцессу. Ответственный подпроцессом видит свой процесс, но понятия не имеет о корневом процессе. Сами подумайте, зачем копирайтеру на русском языке знать обсуждение о развитии захвата рынка Германии учредителями компании. Учредитель видит все от верха до низа. Получается древовидная структура доступа к процессам компании.

3.3. Состояния процесса, права на изменение состояния

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

3.4. Дедлайн процесса

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

3.5. Понятие задачи, как частный случай процесса.

Дробить можно вечно, так можно и до «квантов идей» разделить, однако профита будет никакого. Поэтому в системе можно выделить процессы на которых оканчивается деление — то есть группировка под одним процессом. Такой процесс можно назвать конечным процессом — или просто «задачей» (issue), например разработать вот такую-то кнопочку на сайте, позвонить клиенту. Формально дробить можно продолжить, но в реальности бессмысленно. Любой человек который отвечает за задачу (таким же процессом) имеет право её дальше дробить сам для себя, если это повысит его KPI, но мало вероятно.

3.6. Зависимость задач друг от друга, построение цепочек задач

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

3.7. Очереди и автоматизация.

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

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

4. Выводы

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

5. Реализация

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

1. Это был бы веб сервис — HTML для представления
2. Он был написан на популярном стеке — PHP, SQL =) да топлю за своих!
3. Он был бы топорно простым. Например никаких RTF редакторов в тексте задач и комментариев. Голые стандартные интерфейсы без говна с графикой. Мобайл френдли.
4. Эта система могла бы масштабироваться и становиться CRM, Bug Tracker-ом как частный случай.
5. И моя мечта. Я хотел бы иметь динамический TODO который система самостоятельно мне формирует!!! В таком туду сначала идут блокирующие задачи/вопросы, потом идут те которые сейчас исполняются, далее идут приоритетные. Очень удобно, открыл и вырабатываешь свою бесконечную очередь, просто отключая мозг!!! =)

И все же, если существует подобная удобная система, которая не стоит 100500 долларов. Скажите мне в комментариях.