Вопрос о том, кто именно должен проектировать новые бизнес-процессы (БП), часто становится камнем преткновения при автоматизации предприятий на базе 1С. Программисты часто сталкиваются с ситуацией, когда от них требуют не просто «написать код», но и придумать, как именно должен работать склад, закупки или продажи. В рамках данной статьи мы разберем по шагам зоны ответственности различных сотрудников и определим оптимальную модель взаимодействия между бизнесом и ИТ.
Для начала проанализируем саму суть термина. В среде специалистов часто возникают споры: является ли сугубо техническая операция бизнес-процессом? Рассмотрим две точки зрения, прозвучавшие в обсуждении:
С точки зрения методологии 1С, верным является второй подход. Прием сотрудника на работу, создание архивной копии базы или согласование заявки на расход денежных средств — это полноценные БП. Потребителем в данном случае выступает сама компания, а результатом — стабильность и прозрачность ее работы.
Выясним причину, по которой программист «на фиксе» не должен единолично создавать новые процессы для бизнеса. Основная задача автоматизатора — переложить существующую или спроектированную логику на язык программного кода. Создавать саму логику должны другие люди:
BPMN или EPC), анализируют процессы «as is» (как есть) и проектируют «to be» (как должно быть).Несмотря на то, что программист не должен «придумывать бизнес за директора», его роль в создании процессов огромна. Рассмотрим подробнее, где начинается компетенция ИТ-отдела:
1. Технологические процессы внутри ИТ-отдела. Обслуживание баз данных, регламентные задания, мониторинг серверов — это процессы, которые создаются и регламентируются именно ИТ-специалистом. Например, процедура восстановления системы после сбоя — это критически важный вспомогательный бизнес-процесс, автором которого является системный администратор или ведущий программист.
2. Консалтинг и оценка реализуемости. Проанализируем ситуацию: бизнес хочет внедрить сложную систему распределения бонусов. Программист должен выступить консультантом, объяснив, как это ляжет на архитектуру 1С:Предприятие и не приведет ли это к неразрешимым конфликтам данных.
3. Внедрение мирового опыта (Best Practices). Существует подход, популяризированный крупными вендорами (SAP, 1С в типовых решениях вроде ERP). Программист может предложить бизнесу: «В системе уже заложен процесс адресного хранения, отработанный на тысячах предприятий. Давайте подстроим ваши процессы под логику программы, а не наоборот». Это рациональное зерно часто экономит миллионы на разработке.
Разберем важный тезис: автоматизация хаоса приводит к автоматизированному хаосу. Прежде чем переносить процесс в код, он должен «устаканиться» вне системы. Посмотрим на алгоритм действий при создании нового процесса:
В самой платформе 1С для этих целей предусмотрен объект БизнесПроцесс, который позволяет жестко задать карту маршрута. Рассмотрим пример описания точки маршрута в коде:
Процедура ПередСозданиемЗадач(ТочкаМаршрутаБизнесПроцесса, ФормируемыеЗадачи, СтандартнаяОбработка)
// Здесь определяется исполнитель на основе роли или конкретного пользователя
Для Каждого Задача Из ФормируемыеЗадачи Цикл
Задача.Исполнитель = ПараметрыСеанса.ТекущийПользователь;
КонецЦикла;
КонецПроцедуры
Такой программный код — это уже финализация процесса. Но саму «карту маршрута» (кто за кем идет и какие решения принимает) должен утвердить Владелец процесса (руководитель соответствующего отдела).
Подведем итог нашего анализа. Создание новых бизнес-процессов — это коллективная работа, где:
Задача, БизнесПроцесс или простых статусов документов) для реализации этой логики.Помните, что программист может и должен проявлять инициативу в улучшении процессов, особенно если он видит технические возможности для оптимизации (например, замена ручного ввода данных на автоматическое заполнение через РегламентныеЗадания). Однако ответственность за то, как именно работает бизнес, всегда лежит на его руководителях.