Что входит в понятие «бизнес-правила»
Давайте теперь разберёмся, что такое «бизнес-правила» и какие они бывают. Как следует из самого названия, это правила, которые определяют «как должен работать» конкретный бизнес. Это ограничители, которые направляют действия сотрудников или целые бизнес-процессы в нужном направлении. И эти ограничители:
а) могут устанавливать внешние регуляторы (например, правила бухгалтерского и налогового учета и отчетности)
б) могут вырабатываться отраслью, исходя из ее специфики (например, отраслевые стандарты ISO) или профессиональными сообществами, исходя из «лучших практик» (например, учет по МСФО)
в) может вырабатывать сама компания, исходя из своей специфики, конкурентных преимуществ, стратегии, пожеланий собственника, способа управления и пр.
И если с первыми двумя группами правил все более или менее понятно – можно изучить нормативную документацию, опубликованные стандарты и т.п., то с последней группой все гораздо сложнее.
Во-первых, очень часто эти правила в компании размыты, не формализованы, имеют разное толкование в разных отделах или вообще отсутствуют.
Во-вторых, многие компании имеют склонность «творчески адаптировать» правила из первой и второй группы для решения своих сугубо управленческих задач. Классический пример – небольшая «кастомизация» счетов регламентированного учета под задачи управленческой отчетности. При это первичные данные для формирования этой самой отчетности берутся именно из регламентированного учета (бухгалтерских проводок).
Поэтому первым шагом нужно составить «реестр бизнес-правил», которые могут и должны применяться к каждому бизнес-процессу. Ниже приведен небольшой кусочек такого реестра, составленный на основе моего опыта. Это основной список бизнес-правил, которые нужно собрать и проанализировать для корректной автоматизации процессов управления.
|
Бизнес-правило |
Регламентирующий документ
|
|
Распределение затрат по статьям бюджета |
Бюджетная политика |
|
Распределение затрат по подразделениям |
Бюджетная структура предприятия |
|
Статьи затрат и доходов, правила распределения затрат и доходов по статьям |
Учетная политика |
|
Правила учета и списания ТМЦ по видам ТМЦ и их целевому использованию |
Учетная политика |
|
Правила и критерии выбора поставщиков |
Положение о закупках |
|
Распределение ответственности за закупки по подразделениям |
Положение о закупках |
|
Правила расчета и выплаты премиальной части, показатели расчета |
Положение о премировании (о материальной мотивации) |
|
Этапы производственного цикла, порядок движения сырья, материалов и комплектующих, их трансформации в процессе производства |
Технологический регламент производства |
|
Правила предоставления и размеры скидок клиентам |
Положение о ценообразовании (регламент ценообразования) |
Продолжать этот список можно довольно долго. Кроме того, в разных компаниях один и тот же по смыслу документ может называться по-разному. Но даже если вы найдете и внимательно прочитаете все регламенты предприятия, скорее всего это не решит вашу задачу. Проблема в том, что цели создания внутренних регламентов и цели автоматизации сильно различаются.
Цель любого внутреннего регламента – формализовать общими словами свое видение «как нам надо, чтобы работали наши сотрудники»:
- Чтобы снять с себя «головную боль» - каждый раз отвечать на вопросы «что и как нам делать». Можно отправить читать регламент
- Чтобы отчитаться перед внешними проверяющими органами (например, для прохождения сертификации по ISO). «У нас есть документ» - важно наличие, а не содержание
- Чтобы самому можно было «подсмотреть» и опереться при обосновании, если вдруг возникнут вопросы или что-то пойдет не так.
Поэтому, такие регламенты пишутся профессиональным языком, понятным тому, кто этот регламент разрабатывал.
Цель ТЗ на автоматизацию – описать все правила на уровне типовых объектов внедряемой системы или языка, на котором будущая система будет разрабатываться. И пишут такие документы люди из ИТ отрасли.
В результате возникает системное противоречие:
- Корпоративные регламенты, которые выдает ИТ аналитикам бизнес-заказчик в качестве «детального описания бизнес-правил» не дают ответов на нужные для автоматизации вопросы. Поэтому искажаются и домысливаются ИТ специалистами, исходя из своего опыта или «представления о прекрасном».
- ТЗ, в которое ИТ специалисты перекладывают свое видение, заказчики информационной системы просто не могут перевести на понятный для себя язык. Поэтому также домысливают или принимают «как есть», надеясь на профессионализм ИТ команды.
Ну и самое главное следствие, не имеющее отношение к автоматизации, но критичное для работы бизнеса – потеря управления. Ни в том, ни в другом случае бизнес-правила не выполняются и их сложно проконтролировать:
- Регламенты, непонятные рядовым сотрудникам (не дающие четкие ответ «что и как делать в конкретном случае»), искажаются либо просто игнорируются
- Правила, настроенные в информационной системе, не соответствуют реальности. И поэтому пользователи ищут обходные пути или просто продолжают работать вне системы.
Инструменты формализации бизнес-правил, чтобы их можно было переложить в требования к информационной системе
Чтобы снять это противоречие нужны отдельные инструменты, отличные от ТЗ и регламентов. В своей практике я активно применяю два формата:
1. Графические схемы процессов. Этот инструмент знаком многим, но не все понимаю его основной смысл. Помимо того, что графические схемы просто описывают последовательность действий и ответственных за действия, они позволяют четко визуализировать логику в ситуации жесткого выбора и ограничений.
Например, в производстве выпустили продукцию, по которой есть вопросы к качеству. По итогам проверки ОТК формирует заключение об отклонениях (какие характеристики и насколько несоответствуют). И дальше вступают в действие бизнес-правила:
- Если отклонения по критичным характеристикам (такую продукцию нельзя использовать), и исправить отклонения (доработать) тоже нельзя – она перемещается на склад брака
- Если отклонения критичные, но их можно исправить – перемещается на склад производства с пометкой «доработка»
- Если отклонения не критичные (не влияют на потребительские свойства) – выпускают на склад «неликвидов» для продажи с уценкой
И это все отражается на графической схеме. А для точки принятия решения «как действовать» указываются входные данные, на основании которых выбирается тот или иной сценарий. В нашем случае это:
- Перечень характеристик с параметрами критичности
- Возможно, допустимые уровни отклонений характеристик от нормативных значений
В результате сотрудникам понятно, что и в каких случаях делать и какими данными определяется порядок действий. И эти правила можно «прошить» в информационной системе в виде сценариев. Тем самым закрепить их и заблокировать произвольность в поведении сотрудников. То есть – повысить управляемость.
Как это обычно выглядит (рис. 1):
2. Таблицы соответствий. Этот инструмент удобен в ситуации, когда необходимо свести в одну модель, а иногда и сравнить несколько видов правил из разных областей. Зафиксировать на уровне формул и алгоритмов, чтобы затем их можно было легко сопоставить с объектами внедряемой типовой системы или языка, на котором будущая система будет разрабатываться.
Классическим примером является формализация учетной политики. Дано:
- Набор хозяйственных операций. Допустим, тех же самых, по выпуску и перемещению продукции из производства
- Состав складов, по которым ведется учет
- План счетов и проводки регламентированного учета
- План счетов и правила распределения затрат для целей управленческого учета, например, для более точной оценки и анализа себестоимости
- Требования по документальному оформлению перемещения готовой продукции
Нужно как-то свести эти правила в понятную и четкую модель, по которой:
а) сотрудники могли бы понимать, что в каких случаях и как им делать
б) финансовая служба - контролировать правильность ведения учета и перемещения продукции
в) ИТ специалисты – настроить процессы движения данных в информационной системе
И табличная форма в этом случае является оптимальным инструментом. Например, вот такая (рис. 2):
Самое главное – что эти инструменты могут использоваться не только для формализации правил учета, но и для любых других сценариев, которым требуются четкие правила: предоставление скидок клиентам, способ выбора поставщиков, анализ и работа с претензиями, согласование договоров и др.
Когда и как разрабатывать бизнес-правила
Если отрисовка графических схем процессов требует только знания нотаций описания и умения задавать вопросы участникам этих процессов, то создание таблиц соответствий требует более глубоких компетенций. Необходимо понимать:
- какие факторы могут или должны влиять на сценарий работы сотрудников
- как факторы могут быть связаны между собой – чтобы переложить их на конкретный сценарий, но при этом не усложнить работу компании
- какие данные нужны для установки правил и есть ли общепринятые правила (законодательство и т.п.)
И зачастую при разработке таких правил возникает конфликт интересов разных служб: бухгалтерии и финансовой службы, производства и продаж, договорного отдела и подразделений –инициаторов договоров.
Устранение этих противоречий и выработка оптимальных решений – задача управленческая, требующая системного взгляда на предприятие и понимания специфики бизнеса. Это задача представителей бизнеса: владельцев бизнес-процессов, руководителей бизнес-направлений. Или управленческого консультанта – если руководители не могут выработать эти правила самостоятельно или договориться между собой.
Важно понимать: эта работа – часть общего комплексного проекта автоматизации управления и должна быть выполнена до того, как ИТ специалисты начнут настраивать или проектировать информационную систему. А именно – на этапе формализации требований.
Разработка/уточнение и формализация бизнес-правил – полноценный этап проекта, который часто называют «методологическое проектирование». Из моего опыта он занимает от 2х месяцев до года – в зависимости от степени зрелости компании, ее системы управления, компетенций ТОП- менеджеров. Вариантов всего два.
Если компания достаточно зрелая и выстроенная в части управления – все довольно просто. В этом случае, даже если бизнес-правила не переведены в регламенты, их легко выявить в ходе интервью и вместе с руководителями подразделений перевести в таблицы соответствий, описанные выше. В этом случае работа пройдет быстро, возможно даже не потребует отдельного этапа проекта.
Гораздо сложнее, когда компания переживает этап «управленческой трансформации», когда многие правила не определены, упрощены или размыты, но потребность в них уже существует. В этом случае выработка и формализация правил - длительный и сложный процесс. Будет поиск компромиссов между усложнением деятельности и снижением человеческого фактора. Будет работа с сопротивлением тех, кто не заинтересован в работе по правилам (а такие будут всегда) или тех, кто хочет навязать свои правила другим. Будут этапы поиска оптимальных правил, ретроспективного моделирования по этим правилам – для проверки их адекватности, опытной эксплуатации - возможно «на коленке» в excel, без переноса в информационную систему.
Но если этого не сделать, вы будете бесконечно перепроектировать систему по новые вводные. Либо получите «неуправляемое поведение» вашего продукта, когда одни правила будут вступать в конфликт с другими и вызывать логический (и алгоритмический) коллапс.
О том, как выстраивать эту работу - тема отдельной статьи. Но даже если вы просто сможете видеть «точки влияния» бизнес-правил на то, как работают бизнес-процессы компании, это принесет существенную пользу вашему бизнесу или проекту.