Кто должен работать с бизнес-требованиями в проектах автоматизации?
Во сводах знаний и описаниях профессий написано, что с требованиями должны работать «аналитики». Причем никто не уточняет, какие именно аналитики, с какими требованиями и что должны делать. В итоге все сводится к тому, что аналитиков много, а четкого понимания «кто есть кто» нет. И на выходе в проектах возникает размывание ответственности и «спорные территории» - кто отвечает за ту или иную задачу проекта. В первую очередь это касается:
- выявления и формализации бизнес-целей проекта
- определения состава и содержания работ, которые необходимы для достижения целей проекта
- анализ и сопоставление требований, заявленных будущими пользователями системы с целями проекта – чтобы удерживать контур и не давать проекту расползаться, четко расставлять приоритеты
- выполнения работ, связанных с выработкой и упорядочиванием бизнес-правил, которые должны стать ограничителями при выполнении бизнес-процессов в новой системе
И только потом уже выбирать способ реализации требований в каком-то продукте, перекладывать эти требования в логику конкретной системы, проводить настройки и внедрение.
А это значит, что в проекте нужны разные «виды» аналитиков.
Если рассмотреть работу с требованиями как бизнес-процесс и сопоставить с ролями аналитика, то укрупненно его можно представить примерно так (Рисунок 1).
Рис. 1. Процесс работы с требованиями разных аналитиков
Это моя авторская схема, которая показывает, как распределяются роли аналитиков по всему процессу работы с бизнесом: от определения стратегии до ее воплощения в конкретных инструментах. Конечно схема немного упрощенная. Из нее осознанно вынесен вовне процесс работы с бизнес-изменениями, хотя мы все понимаем, что внедрение ИТ инструментов и бизнес-изменения тесно связаны. Также не детализированы процессы выбора ИТ решения, разработки, тестирования и внедрения, поскольку они не относятся к основному процессу работы с требованиями.
Важно, что эта модель показывает разделение «зон влияния» между разными типами аналитиков и зоны явных пересечений этих ролей. И определяет старт начала работы с требованиями - выявление бизнес-целей и определение бизнес-требований.
Поэтому давайте разберемся, какие виды требований бывают, и как они между собой связаны. Для этого существует известная многим модель Вигерса (Рисунок 2)
Рис. 2. Модель Вигерса: виды требований и связи между ними
Эта модель описывает виды требований, проводит их декомпозицию - от стратегии к реализации, показывает связи и влияние разных видов требований друг на друга.
Вариантов представления модели Вигерса довольно много. Но мне больше всего нравится эта схема, немного уточненная и дополненная с учетом экспертного опыта. Она наглядно показывает: то, что в ИТ принято называть «ТЗ» и даже «функциональные требования», является производным от бизнес-требований. И никак иначе. А сами бизнес-требования являются способом реализации стратегии и целей бизнеса, вытекают из них, а не живут «сами по себе».
Если мы теперь попробуем наложить модель Вигерса на процесс работы разных аналитиков, получится примерно такая картинка (Рисунок 3).
Рис. 3. Виды требований, выявляемые на разных этапах работы аналитиков
Таким образом, в составе команды вашего проекта должны быть специалисты, закрывающие все три роли. В противном случае система окажется «сферическим конем», не отвечающим интересам и потребностям компании.
Как правильно определять бизнес-требования?
Итак, мы формулируем бизнес-требования. И здесь обычно лежит корень всех дальнейших проблем проекта. Как правильно сформулировать требования с позиции бизнеса? И что бизнес-требованиями не является? Приведу пару примеров.
Пример 1.
«Цель проекта- перейти на современную ИТ систему» - говорит вам заказчик. Знакомо, не правда ли?
Понимаете ли вы из такой формулировки, как ИТ система поможет достичь целей бизнеса? И какими критериями вы, как бизнес- заказчик, или ваш внешний заказчик будет оценивать успешность тех проектных решений, которые будут предложены?
А если переформулировать цель вот так: «Снизить стоимость владения ИС на 30% за 5 лет за счет перехода на широко используемые и постоянно развивающиеся ИТ решения». Лучше, не правда ли?
Пример 2.
Заказчик в лице Коммерческого директора говорит вам «Цель - повысить эффективность продаж за счет автоматизации». А если эффективность его продаж вообще никак не связана с отсутствием или наличием ИТ системы, а связана с высокой конкуренцией, территориальной удаленностью клиентов и другими внешними факторами?
Попробуем переформулировать бизнес-требование, например, вот так: «Обеспечить расширение сети магазинов (прирост на 10 в год) за счет создания тиражного ИТ решения управления розницей». И сразу становится понятно, какой конкретно цели в части продаж должна помочь достичь будущая ИТ система. И самое главное, это вполне реалистичная цель и адекватный способ ее достижения в контексте ИТ.
Вывод: для начала нужно научиться правильно формулировать бизнес-требования. Для этого есть несколько критериев, что такое «хорошее бизнес-требование»:
- Направлено на удовлетворение определенной потребности бизнеса (боль, проблема или возможность), отвечает на вопрос «для чего?» (нам нужна ИС, продукт)
- Связано с бизнес- целями, показателями эффективности/результативности компании или отдельных бизнес-процессов, зачастую имеет измеряемые метрики.
- Определяет ценность автоматизации для бизнеса (коммерческую ценность, влияние на финансовый результат)
- Имеет однозначное (четко формулируемое, не абстрактное) толкование
- Может включать в себя пути достижения желаемого состояния, отвечать на вопрос «за счет чего мы будем реализовывать это требование»
- Всегда продуктово независимое!!! Не описывает функции или свойства конкретного продукта, решения, которые должны быть применены
Что еще можно выявить при работе с требованиями, и почему это важно при автоматизации?
Мы все привыкли оперировать абстрактным понятием «ИТ требования» или «Требования к системе». Но если вникнуть глубже, то огромное количество требований, которые так или иначе влияют на конечный ИТ продукт, не являются «функциональными» в прямом смысле. И даже не являются требованиями к ИТ системе. (Таблица 1)
Таблица 1. Виды требований с точки зрения содержания
|
Требования к интерфейсам |
|
|
Требования к отчетам
|
|
|
Требования к НСИ
|
|
|
Требования к интеграции
|
|
|
Требования к специальному оборудованию
|
|
|
Технологические требования
|
|
Но самое главное - все эти виды требований еще и влияют друг на друга. Примерно так (Рисунок 4).
Рис. 4. Связи между разными видами требований
Казалось бы, как требования к отчетам влияют на ИТ инфраструктуру? Напрямую! Хотите видеть все графики в режиме онлайн на планшете, находясь «в отпуске на Канарах» – вот вам и требования к платформе, серверам и каналам связи.
Но и это еще не все. Если мы вспомним модель Вигерса, то в ней есть еще бизнес-правила (Таблица 2).
Таблица 2. Носители бизнес-правил в компании
|
Учетные политики |
|
|
Положения и регламенты |
|
|
Показатели и правила контроля |
|
Бизнес-правила тесно связаны с бизнес-требованиями, хотя ими и не являются. Например, та же учетная политика завода создана не просто так - а для того, чтобы обеспечивать мониторинг и достижение целевых бизнес-показателей по объемам производства, допустимому браку, простоям и т.п.
И они являются «законодателем» по отношению к функциональным требованиям – задают ограничения «по каким правилам должна работать система». Неважно, что там себе думают пользователи на местах.
И вся эта информация - тоже часть работы с требованиями. Иначе вы не сможете грамотно спроектировать и внедрить систему, которая отвечала бы потребностям бизнеса.
Что же делать, если ИТ команда не знает бизнес- специфику (а как правило это именно так), а сотрудники предприятия не могут помочь сформировать целостное представление о компании как о бизнес-системе?
И тут нам на помощь приходит процессный подход. Да-да! Именно умение видеть бизнес через бизнес-процессы и их связи помогает быстро понять содержание работы компании и не упустить важные детали.
Как перейти от бизнес-требований к требованиям к системе?
Чтобы нам перейти от бизнес-требований к системным требованиями (требованиям к функциям конкретной ИТ системы), нужно последовательно пройти ряд шагов ответить на ряд вопросов:
Шаг 1. Определяем цели автоматизации и выходим на бизнес-требования к «абстрактному» (еще не выбранному) ИТ решению.
Ключевые вопросы, на которые нам нужно ответить:
- Для чего нужна эта система?
- Как разработка или внедрение этой системы повлияет на эффективность компании?
Результатом этого шага станут четко сформулированные бизнес-требования, которые затем будут определять и ограничивать содержание нашего проекта.
Шаг 2. Уточняем боли:
- Какие проблемы хотите решить за счет автоматизации?
Этот вопрос нам нужен для того, чтобы еще раз перепроверить цели автоматизации и уточнить бизнес-требования (в первой части статьи я рассказывала о том, как заказчики не всегда корректно определяют цели автоматизации, и что с такими бизнес-требованиями потом невозможно работать).
Шаг 3. Определяем пути решения.
Вопросы, которые нужно задать на этом шаге:
- Что именно нужно автоматизировать (области автоматизации, процессы и бизнес-функции)?
- Как эти процессы влияют на бизнес-цели, соотносятся с бизнес-требованиями к системе?
И вот здесь мы начинаем работать с бизнес-процессами. Нам нужно выделить именно те, автоматизация которых соответствует бизнес-требованиям. И отсечь те процессы, которые с бизнес-требованиями никак не связаны.
Как это делать, мы рассмотрим на примере ниже.
Шаг 4. Собираем и уточняем пожелания к функциям будущей системы:
- Что должна делать будущая система (по каждому процессу или бизнес-функции)?
Очень важно на этом шаге оставаться вне привязки к конкретному решению. Обсуждать требования безотносительно того, какая это будет система (что именно мы будем разрабатывать или внедрять). Здесь мы работаем в зоне, которую Вигерс называет «Пользовательские требования» (см. рис. 2).
Мы должны сопоставлять пользовательские требования с бизнес-процессами, выделенными на Шаге 3. Не давать «поставщикам пользовательских требований» уходить своим полетом фантазии в другие бизнес-области.
И здесь очень важно учесть те требования, которые не имеют отношения к функциям будущей системы. И их тоже важно сопоставить с бизнес-требованиями и включить в контур нашего проекта.
Шаг 5. Подбираем решения
Вопросы, с которыми мы работаем на этом шаге:
- Каким средством (инструментом) эти требования лучше всего решить?
- В каком программном продукте или за счет какого способа автоматизации это лучше сделать?
Вопросы только кажутся одинаковыми, но это не так.
Задавая первый вопрос, важно понимать, что часть бизнес- и даже пользовательских требований не может быть реализованы за счет ИТ системы. Или для реализации потребуется комплекс разных инструментов: специальное оборудование, роботизация и т.п.
А возможно, для начала необходимо будет провести бизнес-консалтинг: уточнить или поменять бизнес-правила, перестроить бизнес-процессы. И только тогда компания получит тот эффект, которого она хочет достичь.
Также именно на этом шаге принимаются окончательные решения: «Что выгоднее: разрабатывать собственную систему или внедрять типовую?» и «Если внедрять типовую, то будет ли это ERP система или микросервисная архитектура?».
А для этого необходимо понимать «предмет автоматизации», т.е. бизнес-специфику.
Шаг 6. И наконец – переходим к способам реализации в конкретной системе
Основной вопрос, на который мы здесь отвечаем: «Какими средствами конкретной ИТ системы лучше всего реализовать пользовательские требования»?
Шаг 7. Сопоставляем инструменты, которые мы выбрали на этапах 5 и 6, с бизнес-процессами, которые мы автоматизируем
Здесь необходимо ответить на следующие вопросы:
- Все ли действия бизнес-процессов, которые мы автоматизируем (автоматизация которых нам нужна для выполнения бизнес-требований) покрываются инструментами будущей ИТ системы? Включая требования к НСИ, отчетности, интерфейсам, безопасности данных и прочие не функциональные требования.
- Поддерживают ли средства будущей ИТ системы бизнес-логику? Не автоматизацию отдельных функций, а сквозную деятельность компании: связи между бизнес-процессами, логику трансформации данных в процессе работы предприятия и пр.
И здесь нам опять же, необходимо обратиться к бизнес-процессам и вникнуть в бизнес-специфику.
Как процессный подход помогает обеспечить соответствие системы требованиям бизнеса
Как я уже говорила выше, умение работать с требованиями через логику бизнес-процессов помогает решить несколько задач:
- ИТ команде:
- Быстро погрузиться в специфику конкретного предприятия и область автоматизации, не имея бизнес-образования или образования в нужной предметной области (финансы, производство и пр.). Понять, с чем связаны те или иные требования пользователей.
- Сопоставлять требования пользователей с бизнес-требованиями, определять практическую ценность тех или иных требований к системе для решения бизнес-задач автоматизации. Удерживать контур проекта в рамках бизнес-требований, не давать ему уйти в сторону или расползтись.
- Обеспечивать полноту собираемых требований для решения бизнес-задач автоматизации. Учитывать не только функциональные, но и не функциональные требования. Комплексно подходить к достижению целей автоматизации
- Бизнес-заказчику, владельцам бизнес-процессов:
- Управлять «хотелками» рядовых сотрудников, оценивать их потребности тех или иных инструментах с точки зрения ценности для компании. Не давать проекту «уйти в бесконечность»
- Четко отслеживать и оценивать эффективность от вложений в ИТ, понимать, какую практическую пользу и в какой области принесут вложения в проект
- Проводить автоматизацию поэтапно (что особенно важно в условиях дефицита бюджета), по мере возможностей. Но при этом сохранять целостность автоматизации и самой ИТ архитектуры - за счет обеспечения сквозных связей между автоматизируемыми областями.
Как это может выглядеть на практическом примере?
Дано: необходимо автоматизировать производственное предприятие. Допустим, по производству удобрений и средств химической защиты растений. Цель автоматизации – сокращение себестоимости производства за счет более точного анализа и управления затратами.
Для достижения этой цели вначале нужно определить предметную область автоматизации. То есть, выделить бизнес-процессы, которые будут влиять на себестоимость. И скорее всего, в случае с нашим заводом выяснится, что основными факторами, влияющими на себестоимость этого конкретного вида производства, являются:
- Себестоимость сырья, часть из которого возится из-за рубежа и имеет плавающие сроки поставки. Это означает, что в контуре нашего проекта оказываются процессы Управление закупками и запасами. Но не все процессы, а только те, которые относятся к цене и срокам поставки, объемам запасов. Нужно работать на выработку баланса между «большой объем, но за меньшие деньги и всегда в наличии на складе» и «сокращение затрат на хранение и замороженных средств в запасах». Соответственно дальше, при детализации этих процессов, нужно будет фокусироваться на тех требованиях к системе, которые помогут решить эту задачу.
- Брак и несоответствия, поскольку к такой продукции предъявляются очень высокие требования по составу входящих компонент, экологической безопасности и пр. И любое изменение в характеристиках сырья может привести к отклонениям в рецептуре. А любая невнимательность на производстве - к браку. Это означает, что в контур нашего проекта попадают процессы:
- Входной контроль сырья – в части выявления отклонений в характеристиках сырья и оценки их потенциального влияния на свойства готовой продукции. Здесь нам важно будет автоматизировать учет результатов входного контроля и принятие решений о допуске сырья в производство.
- Управление производственной документацией (рецептурами и технологическими картами) – той, что задает четкие правила: какого сырья сколько добавить и как обрабатывать, чтобы получить нужную продукцию. И здесь нам важно автоматизировать учет изменений и информирование об изменениях документации – в т.ч. в связи с изменениями в сырье
- Контроль качества в производстве. Начиная с выявления и учета отклонений в процессе производства (на линии) и заканчивая контролем готовой продукции. Опять же, при детализации этих процессов важно будет понять, в каких точках сейчас основные проблемы, приводящие к возникновению брака. И дальше работать с требованиями, позволяющими эти проблемы устранить.
Ну и возможно, хотя это не связано со спецификой отрасли, на конкретном предприятии может выявиться проблема избыточной численности производственного персонала и затрат на ФОТ. И тогда здесь нужно будет сфокусироваться на процессе Оперативное производство. Выявить ручные и трудоемкие операции, которые можно устранить за счет современных ИТ средств (роботизация процессов, датчики измерений на оборудовании и т.п.).
В итоге в периметр проекта войдут два блока бизнес-процессов, по которым собственно и нужно работать с требованиями пользователей.
- Основные бизнес-процессы, требования которых необходимо будет реализовать:
- Производственный учет и Расчет себестоимости – основные процессы, которые нужно будет автоматизировать. И в рамках производственного учета можно сразу рассмотреть варианты оптимизации ручных операций.
- Формирование отчетности по структуре себестоимости.
- Смежные процессы, которые будут влиять на снижение себестоимости:
- Планирование и анализ запасов сырья
- Планирование закупок (в части объемов, сроков и цен)
- Входной контроль сырья
- Контроль качества готовой продукции и управление браком
- Управление производственной документацией - только в части ее актуальности и изменений
И тогда, если вдруг в процессе сбора требований появятся различные «хотелки» (из бухгалтерии – по поводу рег. учета, финансовой службы - по поводу бюджетирования и планирования, закупок - по поводу оперативной работы с поставщиками, и т.д и т.п.), можно задать закономерные вопросы «К какому бизнес-процессу относятся эти требования?», «Включены ли эти процессы в контур проекта?», «Как эти требования влияют на управление себестоимостью?». Появятся обоснованные аргументы для приоритизации требований и исключения тех, которые не несут бизнес-ценности в конкретном проекте.
А это значит, что ваш проект будет соответствовать потребностям и целям компании, вложенные в него ресурсы будут приносить практическую отдачу. И у вас будет меньше конфликтов между ИТ командой и представителями бизнеса, для которой эта команда работает.