Более 3 лет назад на очередном проекте внедрения 1С ERP решил не мучаться с Excel и создать реестр «функциональных требований» в пустой 1С на базе БСП, где множество аналитиков могли бы работать совместно. Спустя 3 года конфигурация постоянно развивалась, появлялись новые артефакты, бизнес-процессы и фактически превратилась в MES систему, которая позволяет проектному IT офису существенно автоматизировать процессы работы команды над IT проектами.
В текущих проектах мы продолжаем придерживаться принципа «нулевой толерантности к MS Office» - то есть все, что нужно аналитикам, программистам, администраторам и архитекторам должно быть внутри программы. Термин MES пришел из производства и переводится как Manufacturing Execution System - система управления производственными процессами. Для IT более правильное название – PSA - Professional Services Automation software.
Программа получила название ERP-tools, слоган «команда-проект-результат» и это один из немногих комплексных продуктов, который можно купить за деньги (на сайте Инфостарта) и без значительного допила внедрить.
Что же является «центром» PSA системы? В этой статье я расскажу, к чему пришло постоянное развитие системы. Безусловно, каждая компания может иметь свое представление и стратегию развития, но на мой взгляд, полученная архитектура является законченной и сбалансированной и ее можно брать за основу дальнейшей кастомизации.
В любом случае, если у вас крупное IT подразделение или IT интегратор любого размера, то придется начинать выбор с этой троицы
- Пустой лист «1С.БСП» - «коробка с карандашами», где все есть – остается только придумать как будет это выглядеть, начать многолетний процесс разработки системы, запастись десятками миллионов рублей (начните с 1 млн. рублей в месяц. В эту сумму войдет владелец продукта, аналитик, разработчик и налоги).
- Таинственная «1С. СППР» (которая есть у всех, но практически нигде не вышла за рамки «функционального моделирования»). Лично я не верю, что доступную нам версия используют в самой Фирме 1С для программирования ERP. Уж больно она простая (не навешана сложными процессами). Бюджет на адаптацию этой системы тот-же от 1 млн. в месяц.
- ERP-tools – поделка в стиле Панк-рок. Ее можно купить и уже с понедельника приступить к проекту цифровой трансформации IT Отдела / IT Интегратора, взяв как основу для дальнейшей кастомизации.
Для начала давайте посмотрим определение, которое дает нейросеть Яндекса:
Цифровая трансформация — это процесс интеграции цифровых технологий во все аспекты бизнеса, что приводит к фундаментальным изменениям в том, как компании работают и предоставляют ценность своим клиентам. Это не просто внедрение новых технологий, а полное переосмысление бизнес-моделей и процессов
Цель цифровой трансформации — сделать бизнес более эффективным, гибким и способным быстро адаптироваться к изменениям на рынке.
Некоторые задачи цифровой трансформации:
- Оптимизация бизнес-процессов. Позволяет автоматизировать и ускорить большинство рутинных процессов, уменьшить количество ошибок и повысить качество предлагаемой продукции и обслуживания.
- Увеличение эффективности работы. Современные технологии позволяют снизить затраты на производство и выполнение различных задач, а также обеспечивают более эффективное использование ресурсов.
- Создание новых возможностей для роста. Цифровые технологии помогают компаниям расширять ассортимент продуктов и услуг, а также географию продаж.
- Улучшение взаимодействия с клиентами. Трансформация позволяет компаниям лучше понимать потребности и предпочтения клиентов, обеспечивает более быстрый и удобный сервис, а также создание новых каналов коммуникации с аудиторией.
Какие предпосылки к цифровой трансформации IT подразделения можно выделить:
- Ваша компания до сих пор использует WORD и обменивается между собой e-mail😊
- Вы не понимаете, из чего складывается себестоимость ваших услуг на достаточно глубоком уровне
- Ваши РП погружены во все процессы, являются их связующим звеном.
Цифровая трансформация не запрещает наличие многочисленных IT систем. Вы спокойно можете использовать разные системы для разных задач, например, чаты Bitrix24, учет часов в JIRA, WIKI, бухгалтерские системы и так далее. Главное тут – оркестрация данными, взаимное использование их и удобство конечного потребителя. Вспомните – когда вы приходите на прием в платную клинику – врачи и администраторы работают в MES системе, никто не открывает WORD и не пишет письма по ключевым бизнес-процессам, так как если у вас НЕ автоматизированы КЛЮЧЕВЫЕ БИЗНЕС-ПРОЦЕССЫ, значит вы их делаете с меньшей скоростью (чем конкуренты) и скорее всего с меньшим качеством. И если вы еще готовите техническое задание в WORD и отправляете его посредством электронной почты – значит вы застряли в конце 20 века!
Цифровая трансформация ERP-tools содержит ключевые подсистемы, и я уверен, что любое IT подразделение, проектный или обслуживающий офис увидит знакомые очертания.
- Функционально-процессное описание используемых в компании ИС (информационных систем)
- Бизнес-процессное управление задачами проектных команд, обсуживающими подразделениями
- Управление дорожными картами проектов развития ИС
- Печатные формы и аналитические отчеты
Далее подробнее. Архитектура ERP-tools содержит следующие уровни (ЦФО/ЦО – центр ответственности).
- Проектный офис. Например, «офис 1С», «офис JAVA», «Портфель Иванова», «Офис» и так далее.
- Проект. Каждый проект принадлежит проектному офису. В качестве проекта выступают как внешние проекты – «Переход с УПП на ERP», так и внутренние, «Bitrix24», «БП», «Замена Confluence&Jira на ERP-Tools» и так далее. Доступ к проекту назначается конкретным пользователям, поэтому даже если у вас сотни сотрудников – каждый будет видеть только то, где он участвует постоянно, либо был призван на отдельную задачу. Также как Проект добавляются внутренние отделы, юридический, финансовый отдел, курьеры и так далее.
После настройки каждый портфель создает перечень информационных систем (проектов), который он эксплуатирует. Таким образом, каждая информационная система становится самостоятельной сущностью. Ее размер не очень важен – это может быть и микросервис с единственным бизнес-процессом и 1 аналитиком, и ERP система с командой из десятков человек.
Начинается все с дорожной карты
- Управление дорожными картами
Ключевой артефакт – древовидный справочник «Графики проектов», который визуализирует дорожную карту. По каждому проекту можно сформировать дорожную карту его развития. Каждый этап карты не только название, сроки, ГАНТ, но и подсчет трудозатрат, доходов и расходов, трудовых ресурсов. В идеале – по всем проектам нужно отрисовать дорожные карты и запланировать их развитие.
Итак, первый шаг цифровой трансформации выполнен – у вас есть перечни ЦО (центр ответственности), информационных систем и IT проектов, их графики развития с ответственными и сроками. Как правило средний и крупный бизнес – это десятки и сотни основных и вспомогательным систем, сервисов.
Вы пока не знаете о кросс-функциональных связях этих систем и о их назначении – что, как и для кого они делают, а некоторые может и перестали быть нужными. Вот для этого есть вторая подсистема, которую коротко можно назвать ФМ (функциональное моделирование) и это второй шаг цифровой трансформации
- Функционально-процессное описание используемых в компании видов ПО (ФМ)
Данная подсистема позволяет описать - что, зачем и как делают эти десятки и сотни видов ПО и ИС, которое используется в компании.
- Бизнес-процессы (что нужно делать)
- Шаги процессов (функции) (как делать)
- Объекты метаданных (какие объекты задействуются)
- Функциональные и нефункциональные требования (особенности выполнения)
- Функциональные разрывы с техническими заданиями и протоколами испытаний (доработки)
- Визуальные инструкции (четкая схема выполнения)
- Схемы бизнес-процессов в формате EPC
ФМ создавалась для возможности описания модели ERP, а это значит, что она с легкостью опишет систему любой сложности. Подсистема позволяет сформировать фактическую полную инструкцию по работе каждого процесса. На этом этапе вы можете получить WIKI систему, описывающую все используемые вами виды ПО, а также сценарии работы с ними по ролям, фактически собрав должностные инструкции сотрудников.
Вместо поиска методом «Ctrl-F» в «вордоподобных» WIKI системах – все ваши артефакты записываются в базу данных, учитываются их особенности и жизненные циклы, уникальный реквизитный и статусный состав. Вы получаете не огромный сплошной текст с перекрестными ссылками, а настоящую библиотеку/картотеку, где невозможно потерять информацию.
Итак, второй шаг трансформации – вы описали как взаимодействует каждая информационная система с пользователями и другими системами, интеграционные потоки, ролевые модели, выявили и зафиксировали инструкциями правильное выполнение многочисленных процессов. И не только «внешние» - когда вы коммуницируете с заказчиками, но и внутренние, например, процедура DEVOPS и даже «офисные», когда вы задействуете ресурсы внутренних служб или других «портфелей», например, юристов для подготовки договора и администраторов для настройки клиентских баз данных и сетей, бухгалтеров для выставления первичных документов. Вы с удивлением узнаете, что одни и те же процессы разные сотрудники выполняю по-разному!
Пора переходить на следующий уровень цифровой трансформации – бизнес-процессное выполнение задач.
- SD (управление задачами)
Данная подсистема состоит из основного инструмента - «Заявка», но так получилось, что этот артефакт оказался самым сложным. Подобно транспортным клеткам крови гемоглобину – Заявка способна любой проектный артефакт провести по бизнес-процессу выполнения. например, Функциональное требование от согласования ТЗ через релизы и протоколы испытаний и вплоть до актирования, получения денежных средств и возврата оригиналов документов.
Для любителей представления в стиле канбан есть соответствующий интерфейс. В ходе работы выяснилось, что канбан-представление интереснее линейным сотрудникам (удобно смотреть "мое"), а табличное – руководителю проекта, так как позволяет видеть генезис шагов процесса от 1 до последнего.
Бизнес-процесс «платное выполнение доработки» может быть описан как 12 последовательных шагов (и 2 параллельных), и заявка умеет выполнить последовательные действия и привлекать на каждый шаг различных ответственных лиц –архитекторов, аналитиков, бухгалтеров и даже клиента. Но ключевое отличие от обычных трекеров в том, что физически создается 1 заявка, у которой постепенно меняется «услуга» и «ответственные», вместо «триггерного» создания новых заявок.
Коммуникация Заявки с клиентом при необходимости ведется с помощи встроенного почтового клиента.
При активной разработке будет запущены десятки параллельных задач по отдельным требованиям, которые будут обгонять друг друга и гарантированно следовать к финишу по принципу «выстрелил и забыл». Руководителю не нужно быть связующим звеном между шагами, не нужно вглядываться в эксель таблички, чтобы понимать – на каком этапе находится текущий вопрос.
Сотрудники будут оповещаться о новых задачах, комментариях. Считается SLA, а это значит, что выполнение всего сложного процесса будет ускоряться. Также следует упомянуть, что каждый процесс это только 1 заявка (а не 12) и в ней будет сохраняться вся история переписки с клиентом, например, точные даты согласования ТЗ и бюджетов. Личные почты сотрудников сильно разгружаются, а канбан доска будет содержать только актуальные задачи.
По мере запуска всех «сложных» процессов в компании активно задействуются внутренние службы – бухгалтерия, юристы, кадры. В нашем случае мы действительно можем эффективно контролировать десятки и сотни запущенных процессов и не отвлекаемся на шаги, которые в данный момент не можем начать, а маркировка SLA будет обращать внимание на запаздывающие заявки.
В заявках и канбане вынужден заметить следующее. В видео от создателей трекеров часто показывают только канбан доску «программистов». Там начинается с колонки «новая», далее «в работе», далее «на тестирование», «в релиз», «на проверке аналитиком», «завершено». Я считаю это нереалистичным. Во-первых, а где колонка «разработка ТЗ», «Проведение испытаний» и так далее. Предполагается, что эти колонки находятся на ДРУГИХ досках, а тут доска разработки. Вот как раз множественность досок я и считаю проблемой. Методологи трекеров зачем-то перемешивают понятие статус и услуга. Очень часто в компании только одна доска – «доска разработки», а остальные этапы и задачи других отделов делаются в разных эксельках.
Статусы в ERP-tools это только:
- Новая
- В работе
- Ожидает
- На проверке
- Выполнен
- Отменен
Этот исчерпывающий список подходит и для программиста, и для аналитика, и для бухгалтера, и экскаваторщика. Это статусы выполнения любой задачи.
А вот Услуга – это что именно выполняется. По примеру выше – у нас 12 услуг в процессе, начиная «Создание ТЗ, отправить ФА…» - это задача, в данном случае Аналитика, который должен ее выполнить и отправить в статус «На проверке». Далее ФА должен выполнить свой кусок услуги = «… ФА согласовать ТЗ». То есть «согласовать ТЗ» не может быть колонкой канбан доски. Фактически канбан более сложного чем АМЕБА процесса должен выглядеть так – задача должна подобно печатной машинке идти по статусам до финиша «Выполнен» и переходить на новую строку с услугой и вот такое представление является достаточно наглядным для руководителя. Что лучше – все задачи в статусе «на проверке» по услуге 1 или все задачи в статусе «Новая» по услуге под номером 12?
Трекеры на популярных сайтах все какие-то неприспособленные даже для двухэтапной задачи, доски в YT вообще являются какой-то непонятной сущностью по отношению к проекту. Так и не разобрался как «правильно» вести учет с точки зрения методологов Яндекса. Видео с реальными сложными кейсами очень плохо находятся. В канале техподдержки YT предлагают создавать задачи и бизнес-логику через API программированием на python. Опять продажа «коробки с карандашами».
ERP-tools в этом плане по всем своим подсистемам имеет подробное описание сценариев использования и никаких упрощений не допускается «допустим у вас компания с 1 сотрудником и 1 проектом и 1 задачей». Нет, «допустим у вас 600 человек ведут 300 проектов - вот так работает задачник, где запускаются десятки сложных маршрутов с десятками шагов внутри".
Кроме бизнес-процессного выполнения задач можно фиксировать трудозатраты и привязывать их к непосредственным артефактам, например, из подсистемы «ФМ». В конце проекта вы сможете увидеть, сколько потратили (часов/рублей) на запуск отдельной процедуры, выполнение отдельного технического задания, или реализации какого-то раздела в целом, например, запуск МСФО. При этом, вы можете сохранить процедуры учета трудозатрат во внешних системах, которые как правило имеют API и могут спокойно синхронизироваться с ERP-tools.
В качестве примера хорошо себя зарекомендовали следующие «сложные процессы»
-
- Инициация, разработка, релиз и сдача доработки заказчику
- Подготовка, согласование протокола встреч заказчика с описанием принятых решений и контролем за выполнением задач, поставленных Заказчику и Исполнителю в ходе встречи. Чрезвычайно важно получать ОК по всем вопросам встречи
- Поиск сотрудников на проект. Задача либо переводить нового аналитика в проект либо дает поручение HR о поиске на рынке
- Подписание договора. Инициирует создание драфта, двустороннее согласование, обмен оригиналами
- Возврат оригиналов документов курьерскими службами
- Любые процессы в которых 2 и более шага с привлечением 2 и более сотрудников уже имеют смысл проводить в форме бизнес-процессной заявки. Одношаговые задачи/поручения как правило лучше проводить без использования «Заявок», а через механизм «Заметок»
Подсистема SD и Заявка как транспорт может обеспечить бизнес-процессное выполнение этапов Дорожной карты. Это позволяет не усложнять Графики проекта более мелкими ветками-подэтапами, что существенно упрощает ее визуализацию. Таким образом, выполнение мелких шагов Дорожной карты отдается на «аутсорс» в систему SD для бизнес-процессного выполнения. Разумеется, это касается выполнения как стандартных (повторяющихся) бизнес-процессов, так и уникальных – когда заявку можно собрать из уникальных шагов
Итак, за 3 шага вы полностью описали свой IT ландшафт, его процедуры и научили сотрудников выполнять рутинные и уникальные процессы быстро и точно с контролем SLA. Не может быть такого, чтобы эффективность проектных и внутренних офисов не улучшилась бы хотя бы на 50%. Но скорее всего вы заметите, что вам удается выполнять больше клиентских задач и если раньше в проектах внедрения ERP команда успевала за 2 месяца выполнять условные 20 доработок, то теперь это количество увеличилось до 50, а сами доработки стали более качественными, сложными (с технологической точки зрения), по всем появились ТЗ и протоколы испытаний, требования перестали противоречить друг другу, так как организованы в базе данных, где появление дубликатов или противоречивых требований сильно осложнено. Можно считать положительным результатом первых этапов, что наиболее дорогостоящие сотрудники – руководители проектов и архитекторы могут выполнять/контролировать/лидировать в 2 раза больше отдельных проектов, а это уже существенные выгоды.
Чтобы получить реальные метрики работы компании нужна аналитическая отчетность и это следующий шаг цифровой трансформации
- Отчетность и печатные формы
У вас под рукой находятся все необходимые артефакты работы: ФМ, SD, Дорожной карты. Осталось придумать какие данные контролировать и как отрисовать сложные дашборды. Но сначала нужно выделить несколько самостоятельных направлений отчетности
- Отчет о состоянии проекта (ФМ)
Для контроля актуальности статусов бизнес-процессов есть самостоятельный отчет, который позволяет видеть в процентах процесс развития проекта – от выявления бизнес-процесса до его полного описания инструкцией. Данный отчет позволяет фиксировать % выполнения проекта по функциональному моделированию на конкретную неделю. Вы всегда можете понять какие процедуры и функции эксплуатируются, по каким сейчас идут доработки, какие требования реализуются и кто их придумал и как ваши системы работали до появления новых требований.
- Консоль запросов
В вашем распоряжении «Консоль запросов», которая позволит построить отчет любой сложности на основании любых данных системы
- Универсальный отчет
Для тех аналитиков, кто ленится освоить язык запросов.
- Конструктор печатных форм
В пользовательском режиме можно настроить практически любые шаблоны печатных форм любых артефактов и при необходимости получить выгрузку в WORD, например, для отправки клиенту по почте. Например, в «отчете по требованию» находится как информация из «требования», так и связанный контекст – и текст ТЗ, и протокол испытаний, и даже выписка из Инструкции где наглядно показано как это требование выполняется. Все что можно соединить консолью запросов в структурный вид – может быть выведено в форматированный WORD.
- Отчет PL и бюджетирование
Рекомендуется выделить несколько «уровней» отчетов
- Уровень компании в целом (портфели)
- Уровень Портфеля
- Уровень Проекта
- Уровень отдела
На каждом уровне можно придумать набор финансовых и нефинансовых метрик, научить запросом их собирать и ежемесячно контролировать, например,
- Выручка (по типам),
- Валовая прибыль
- Загрузка
- Выполненные бизнес-процессы
- Штатная численность
- KPI (например, WIP, chargeability, текучесть кадров, просрочка и пр)
Как правило финансовые показатели хранятся в этапах Дорожной карты и загружаются в т.ч. из внешней финансово-учетной системы. Другие показатели можно также загружать из внешних систем и хранить в различных документах системы для вывода в отчет
Мониторинг данных показателей по каждому ЦФО позволяет видеть положительные изменения в компании, управлять этим движением.
Про дашборды не скажу ничего, так как они проигрывают табличному выводу. Ключевая задача – это не дать инструмент выдачи данных «по запросу», а дать стабильный статичный отчет, который выводится постоянно и все цифры анализируются в динамики и по сравнению с плановыми данными. Но с другой стороны, любые отчеты можно дописать – это же 1С.
Итак, ключевые цели цифровой трансформации выполнены
- Описана IT архитектура и инфраструктура, планы развития и WIKI системы по работе с каждой информационной системой компании.
- Описаны и автоматизированы внутренние и внешние бизнес-процессы. Скорость и качество контролируется на основании объективной статистики.
- Создана система объективной оценки влияния нефинансовых показателей на финансовые. Компания готова к кратному росту основных показателей – выручки, прибыли, количества сотрудников
Какие есть планы по развитию ERP-tools
- Кроме указанных подсистем есть утилитарный продукт – подсистема управления Загрузкой начальных данных, которая позволяет полностью отказаться от привлечения программистов в пользу low-code робота 1С. Тестировщик. Это как минимум экономия 1 млн. рублей в проектах внедрения ERP.
- Моделирование бюджета проекта реализовано. Ждем первых практик применения. Идея в создании «шаблона проекта» с красивой дорожной картой и нормативами сотрудников по ролям. При моделировании нового проекта можно довольно быстро получать финансовые оценки исходя из объема (разделов).
- Мечтаю понять, как добавить новые элементы графической схемы к платформенным объектам, например, кружок как «начало». Тогда можно будет рисовать схемы в формате а-ля bpmn 2.0 прямо в 1С. Если есть у кого знакомые, кто дорабатывают Платформу – попросите добавить элементы из библиотеки bpmn 2.0 и тогда и ERP-Tools и СППР будет использоваться для отрисовки схем.
- Распределение ресурсов компании по проектам. Есть некий «аккаунт» - «Отдел программирования», там много людей разных специализаций и другие аккаунты, а точнее их проекты могут резервировать данные ресурсы на период от месяца. Для более качественного контроля и управлением занятостью сотрудников.
- Интеграция с ЯндексТрекер готова, но не могу придумать сценарий использования заявок в ЯТ и их досками. Не понимаю. Работа в «тонком клиенте 1С» на порядок приятнее чем в web-версиях трекеров. По всем сделанным интеграциям основной принцип такой - загрузить Заявки из внешних трекеров в Заявку в ERP-Tools, там с ней работать и изменение статусов возвращать в внешние системы.
- Интеграция с ITMS365 тоже практически завершена. Там очень непонятное API, но обмен заявками работает. Ждем желающих продумать сценарий и запустить.
- Мобильное приложения для Заявок. Также не могу придумать, какой объем информации из заявки туда выводить, какие манипуляции можно передать туда.
- Интеграция Telegram существует и информирует о новых действиях, ожидаемых от пользователя. Видимо надо развивать бота, чтобы из оттуда можно было получить больше контекста, например, перейти по ссылке и увидеть саму заявку. Также пока непонятен сценарий работы.
Приятного управления компанией! Больше видео в плейлисте инструкций и генезисе системы
