Естественные противоречия бизнеса, или как не развалить компанию в процессе автоматизации

Меня зовут Анастасия Золотцева. Ранее я была финансовым директором, затем ушла в 1С. Этот статья родилась из опыта – из тех проблем, с которыми многие сталкиваются. Неважно, приходим ли мы как подрядчики на проект автоматизации или мы внутренняя IT-служба – так или иначе мы видим противоречия между подразделениями в бизнесе, какие-то конфликты, которые накладывают отпечаток на нашу работу.

Наиболее яркий и очевидный конфликт – между производственным и торговым подразделениями. У них разные KPI, разные задачи. Исходя из этого, в общем процессе компании, который включает реализацию готовой продукции, им часто трудно договориться. Отдел продаж в первую очередь заинтересован в скорости и увеличении оборота. У производства свои приоритеты, они процессники, для них важны качество и другие параметры. И, соответственно, при автоматизации подобного подразделения мы часто слышим противоречивые требования от этих подразделений к части общего процесса.

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

Я расскажу про инструменты аналитика, которые помогают:

• Собрать и проанализировать бизнес-правила,

• Выявить противоречия бизнес-правил и требований и возможные пути их устранения,

• Корректно собрать функциональные требования,

• Не развалить компанию, а найти выходы из противоречий в ходе автоматизации.

Бизнес-правила и требования к системе. Откуда берутся конфликты

Бизнес-правило – это сформулированное ограничение, допущение или порядок работы компании/отрасли и принятия рутинных (операционных) решений.

Все мы, наверное, слышали от ключевых пользователей «Мы всегда так делаем». Неважно, задокументировано это или нет – есть некое правило в бизнесе, которому мы привычно следуем. Например: «Мы всегда отгружаем товары в течение трех дней – это наше правило». Хотя. может быть, это правило и не зафиксировано в документах.

У нас в компании сбор бизнес-правил на проектах или в процессе деятельности, как правило, существовал где-то сбоку. Мы сначала собирали цели, затем начинали собирать требования. С бизнес-правилами не работали – на этапах что-то фиксировали и шли дальше. О том, что происходит, если мы игнорируем бизнес-правила или решаем, что в этот раз можно пройти мимо, расскажу ниже.

Виды бизнес-правил

• Условия. Заказчик заплатил, мы ему отгрузим; не заплатил – значит, отгрузки не будет.

• Факты (сведения о заказчиках, которые должны у нас храниться). Они существуют, но не очень сильно влияют на нас с точки зрения конфликтов. Факты мы просто фиксируем и учитываем при формировании требований.

• Правила. Они могут оказывать влияние на нашу работу, потому что определяют вариативность действий.

Анализ бизнес-правил

Обработка бизнес-правил проводится в несколько этапов:

• Собрать сведения из явных и неявных источников,

• Описать,

• Валидировать,

• Верифицировать.

Этап сбора источников бизнес-правил

Источниками бизнес-правил являются:

• Отраслевые регламенты (регламенты компании). Если они есть, это очень хорошо, мы можем их прочитать, ознакомиться и выявить бизнес-правила.

• Отраслевые стандарты.

• Стейкхолдеры, владельцы процессов чаще всего являются основным источником бизнес-правил.

• Корпоративная культура. Очень важно внимательно слушать все, что нам говорят, и обращать внимание на какие-то догмы, за которые борется клиент. Когда они говорят: «Мы всегда так делаем», – это не обязательно означает, что они не хотят менять систему, которую мы собираемся заменять. Это скорее говорит о том, что в бизнесе существует какое-то устоявшееся правило, регулирующее работу клиента, и нам важно это учесть.

Этап описания

На этапе описания бизнеса необходимо учитывать бизнес-правила. Это не требования к системе, а описание бизнеса.

• Бизнес-правила формулируют на языке бизнеса. Правила формулируют в той терминологии, которая понятна, прежде всего, пользователю.

• Бизнес-правила описывают работу бизнеса. Мы не формулируем их как требования к системе. Не что должна делать система, а что должно проходить в рамках бизнеса.

• Бизнес-правила подчиняются бизнесу. Важно помнить: поскольку бизнес-правила – это собственность бизнеса, а бизнес – вещь, которая изменяется с течением времени, вполне нормально, что они могут меняться. Они подчиняются бизнесу. Даже только что собранные бизнес-правила могут быть пересмотрены спонсорами процесса. Спонсоры могут сказать: «Несмотря на то, что мы всегда так делали, сейчас это не отвечает ключевой цели. Мы собираемся менять свою работу, что впоследствии повлияет на систему».

Этап валидации

На этапе валидации необходимо проверить:

• Целевые показатели бизнеса. Проверяем, правильные ли бизнес-правила мы записали, соответствуют ли они целевым показателям бизнеса.

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

• Критерии приемки и оценки. Убеждаемся, что правила соответствуют нашим критериям приемки и оценки, и что движение идет в нужном ли направлении .

• Метрики и ключевые показатели. Проверяем, связаны ли правила с метриками и ключевыми показателями самого бизнеса.

Этап верификации

На этапе верификации проверяется правильность описания правил бизнес-процесса:

• Однозначность бизнес-правил,

• Согласованность бизнес-правил как внутри команды, так и с бизнесом,

• Понятность бизнес-правил бизнесу,

• Выполнимость бизнес-правил в целом.

Далее нужно собрать требования, валидировать и верифицировать их, а также трассировать требования с бизнес-правилами.

Противоречия бизнес-правил и требований

Что будет, если пропустить этап работы с бизнес-правилами, или не включить их в проект вообще?

Допустим, мы собрали разные требования и цели. Бизнес-правил у нас не было. Требования были невнятными, непонятными, местами противоречивыми, и на некоторых этапах работы их не принимали. Мы работали два месяца, но результат оказался невостребованным. Возникает конфликт не только между нами и заказчиком, но и внутри самого заказчика, потому что мы собирали требования с одного подразделения, а сдали функционал, который востребован разными подразделениями. Для одних он идеально подходит, а для других – совсем нет, хотя пользоваться будут все. И разгорается конфликт внутри заказчика: крики, ор и драки. А мы посреди этого стоим и думаем, что делать дальше.

Пример бизнес-правила:

• ГЕК всегда привязан к линии и должен быть заранее распечатан. По факту выпуска продукции ГЕК должен быть нанесен на паллет.

• Один ГЕК должен содержать только один ПЕК продукции.

Для отслеживания этого используются условные номера: номер на линии, который мы привязываем к партии, и идентификатор самой продукции.

Валидация требований

Казалось бы, где тут могут возникнуть проблемы? Но эти требования и правила нам передало производственное подразделение. Когда же мы начали подавать требования для торгового подразделения, выяснилось, что они не подходят. Мы допустили ошибку.

• Неправильно: проводить валидацию требования только с заявившим требование пользователем. Мы не валидировали требования с другими заинтересованными сторонами. То есть мы получили согласование у ключевых пользователей и их руководителей, а у торгового подразделения – нет, потому что казалось, что они тут вообще ни при чем.

• Правильно: проводить валидацию со всем кругом потенциально заинтересованных лиц. Для себя мы выделили рекомендацию: в следующий раз стоит чуть внимательнее относиться к определению заинтересованных сторон и совместно с заказчиком моделировать матрицу заинтересованных лиц, чтобы понять, пересекаются ли их процессы внутри компании или холдинга.

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

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

Было принято решение:

• ГЕК должен быть заранее распечатан, а отслеживание продукции осуществляется по ПЕК. По факту выпуска номер партии должен быть привязан на паллет.

• Один ГЕК может содержать в себе несколько ПЕК различной продукции.

Верификация требований

• Глоссарий. Требования по переупаковке со стороны логистики используют свою терминологию, полностью отличную от производственной. Так, наши ГЕКи-ПЕКи у производственной компании называются одними названиями, а у торгового – совсем другими. Когда мы спрашивали, одно ли это и то же, все настойчиво отвечали – нет. Это происходило до тех пор, пока не стало понятно, что на самом деле это одно и то же. Все согласились – внутри компании часто существует своя устоявшаяся терминология, и представители разных подразделений даже не осознают, что используют одни и те же понятия. Особенно это характерно для больших и очень автоматизированных компаний, где большинство ключевых пользователей – операторы.

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

• Поиск конфликтующих требований. Необходимо искать противоречия по требованиям, проводя анализ заинтересованных сторон и выявляя возможные конфликты.

Трассировка бизнес-правил и требований

Осознав допущенные ошибки, мы вернулись к созданию матрицы, где сверху – правила, снизу – требования. Зеленый цвет означал согласующиеся требования и правила, а рыжий – конфликты или несоответствия, которые нужно устранить.

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

Посреди конфликта

Конфликт – стрессовая ситуация, особенно если заказчик недоволен, а нам кажется, что мы справились с задачей. Мы не понимаем, что происходит. Важно не терять голову, не поддаваться эмоциям. Необходимо проанализировать ситуацию, понять, какие этапы работы мы пропустили, к чему необходимо вернуться, и синхронизировать действия с заинтересованными сторонами.

Правильный анализ бизнес-правил:

• Снижает риски,

• Минимизирует конфликтные ситуации в проектах,

• Помогает более точно, качественно прорабатывать требования.

Для анализа бизнес-правил используют:

• Матрицы трассировки и оценку влияния бизнес-правил на бизнес-процессы,

• Критерии принятия и оценки.

Что делать и что не делать с конфликтами:

Не нужно:

• Пытаться всех спасти и примирить,

• Искать истину и виновных.

Нужно:

• Помнить, что мы в первую очередь делаем системы – нам важно получить необходимые сведения,

• Ищем в конфликте информацию для анализа,

• Выявляем причины и поводы столкновений,

• Фиксируем и смягчаем все риски,

• Доносим информацию руководству.

Мораль

• Не стоит выводить анализ бизнес-правил за рамки проекта, не стоит его игнорировать.

• Не надо бояться конфликтов и противоречий. Если мы выявляем какое-то противоречие, то мы сможем найти ограничения для нашей системы, требования качества для нашей системы.

• В спорах рождается истина. Главное в этом споре не участвовать, а анализировать его и не увязать в борьбе за позицию кого-то из стейкхолдеров.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.