Как подготовить требования к проекту автоматизации?

Здравствуйте коллеги.
Мы подготовили для вас очередной подкаст в рамках проекта «Бизнес в порядке». Управляющий партнер компании «Константа» Андрей Шишкин рассказал о том, как подготовить требования к проекту автоматизации, по каким параметрам судить о проекте при выборе той или иной технологии подготовки и где найти примеры подобных документов.

Почему тема подготовки требований так актуальна и в чем заключается важность этого шага для итогового успеха ИТ-проекта?

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

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

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

А есть ли какие-то параметры, от которых можно отталкиваться при выборе той или иной технологии? Ведь наверняка технологии подготовки к проекту для всех проектов разные.
Действительно, все проекты отличаются. Причем отличаются по разным параметрам. И говорить, что есть одна универсальная технология для решения любого проекта – это то же самое как говорить, что для любой задачи, которая перед вами бы не стояла, есть один универсальный продукт, (название которого мы все знаем :)), который решит все ваши беды. На самом деле не так. Конечно же проекты разные и подготовка к проектам разная.
Мы выделяем два основных параметра, которые влияют на выбор технологии подготовки к проекту автоматизации.

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

• Автоматизация одной задачи в рамках одного подразделения

Самый простой пример – это автоматизация трейд-маркетинга. Есть конкретная функция – планирование и анализ результатов проведения трейд-маркетинговых акций. Да, есть стыки с другими подразделениями, но принципиально мы автоматизируем деятельность одного подразделения в рамках одной задачи.

• Автоматизация 5-10 функциональных задач в рамках 2-3 смежных подразделения

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

• Автоматизация большого количества функциональных задач (может исчисляться десятками) в рамках 4-8 подразделений

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

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

То есть, насколько сильно процессы, которые планируется автоматизировать, будут отличаться от того, как есть сейчас. И здесь опять же мы выделяем три категории:

• Автоматизируем процесс в чистом виде как он есть сейчас

Например, в отделе трейд-маркетинга есть Excel-файл, который автоматизирует деятельность трейд-маркетологов. И у заказчика есть задача – сделать один в один как это сделано в Excel (как они планируют и как подводят итоги акций). То есть заказчик хочет уйти от зависимости от Excel и от ошибок, который потенциально он несет. Мы автоматизируем процесс, но принципиально оставляем его таким же, какой он есть.

• Принципиально процесс не меняем, но проводим локальную оптимизацию на отдельных его участках с учетом использования новых ИТ-инструментов, которые раньше были нам недоступны

Например, рассмотрим задачу планирования заявки на производство. У многих компаний этот процесс выстроен в Excel. В реальности параметров, которые влияют, например, на прогноз отгрузок, и которые мы хотели бы учитывать, порядка 10. При этом в Excel мы можем учесть всего 2-3 параметра. Соответственно при автоматизации такого процесса, когда у нас уже выделены все роли, в т.ч. планировщика, не менять принципиально порядок протекания процесса, но на каждой отдельной точке за счет использования новой ИТ-системы поменять исполнение функций, обогащая ее.

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

Обычно такие проекты автоматизации происходят в поддержку организационных изменений. Например, когда компания выделяет торговый дом. Есть два предприятия, которые занимаются обслуживанием клиентов. На каждом из них есть выстроенные процессы обработки заказов. Когда выделяется торговый дом, процессы начинают меняться: появляются новые люди, новые роли, процесс начинает протекать по-другому. То есть мы автоматизируем то, чего не было до момента построения системы автоматизации.
На пересечении этих двух параметров у нас появляется 9 вариантов проекта, под которые мы должны выбирать свою систему подготовки требований.


А какие виды подготовки требований существуют, если наложить их на те параметры, о которых ты сейчас рассказал?

На основе 16 лет практического опыта автоматизации мы выделяем три вида подготовки к проекту:

• Подготовка функциональных границ

Это модель подготовки к проекту, которая находится наиболее близко к так популярному в последнее время Agile-подходу. Я против Agile ничего не имею, но часто его начинают использовать там, где его использовать не надо, как часто бывает с новыми инструментами. Однако, даже в проектах автоматизации бизнеса Agile тоже возможен.

Сюда подойдет случай, когда мы автоматизируем одно подразделение и несколько задач либо без изменений, либо с локальной автоматизацией. Тот же трейд-маркетинг. Или клиентский сервис в режиме смены одной платформы на другую: компания работает на «1С:УТ 10» и хочет перейти на «1С:УТ 11», либо на нашу коробку «ERP4FOOD», и на первом этапе нужно перенести процессы один в один. В таких случаях достаточно очертить границы проекта и не заниматься глубоким описанием, как должен выглядеть целевой порядок. Потому что, либо задача небольшая, и нам понятно – как будут протекать эти процессы, либо мы понимаем, как переносить существующий функционал, и когда в процессе проекта возникает какой-то вопрос, просто смотрим на то, как это работает сейчас.

В таких проектах достаточно описать функциональные границы:

1. что является информационным входом задач проекта, а что выходом,
2. какой список функций мы берем в работу,
3. принципиальные требования к каким-то отдельным функциям или экранным печатным формам, которые мы хотели бы зафиксировать как требования к проекту.

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

• Подготовка функциональных требований

Этот подход применим в проектах, которые, как правило, затрагивают несколько подразделений. И при этом мы хотим автоматизировать не просто то, как это есть сейчас, а хотим выполнить хотя бы локальную оптимизацию.
Когда мы автоматизируем клиентский сервис или производство, в этих проектах даже если иногда на входе клиент говорит, что хотел бы просто из одной системы перенести в другую (старая система не поддерживается, не обновляется, большое количество историзмов, с производительностью проблемы), в реальности переход один к одному делается редко. Всегда возникает желание: если уж тратить ресурсы на проект, то логично выполнять как минимум локальную оптимизацию.

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

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

Один элемент карты процессов – это одна функция, требования к которой будут зафиксированы. Причем как требования относительно функциональности данных задач, так и требования к их техническому обеспечению. Здесь у нас уже появляется такое что-то более похожее на техническое задание. (Я, кстати, термин «техническое задание» принципиально нигде не употребляю, потому что он очень заезженный, и под ним все понимают свое. В данном случае это функциональные требования).

Важно также правильно определить, кто должен готовить эти требования. Если для подготовки функциональных границ нам достаточно иметь квалифицированного функционального заказчика, то подготовка функциональных требований – это уже техническая история. Здесь нужен системный аналитик. Человек, который глубоко понимает систему как взаимосвязь элементов и способен на этапе формирования требований отсечь те вещи, которые нет смысла формализовывать, потому что они потом будут неисполнимы. Но так как принципиально не предполагается каких-то бизнесовых изменений, а мы все-таки опираемся на то, что это сохранение общей логики процесса в локальной оптимизации за счет использования ИТ-инструментов, то здесь работает именно системный аналитик, а не бизнес-аналитик.

• Регламентация целевых процессов и их автоматизация

Это работы, направленные либо на существенное изменение процессов, либо на решение большого количества задач, (либо и то, и другое).
Например, выделяем торговый дом. Процессы будут сильно меняться. По сути нам нужно построить новые процессы в рамках ИТ-проектов, но на самом деле должны достигаться еще и бизнесовые выгоды.

Или, например, когда мы занимаемся планированием заявки на производство, и наша цель – повысить клиентский сервис с 94 до 98 процентов и при этом снизить уровень списаний с 2 до 0,5 процента. То есть это бизнесовая задача, и решается она не только через систему, а еще через изменение самих процессов.

Соответственно, отличие регламентации от функциональных требований в том, что при регламентации первую скрипку исполнения этой работы должен играть именно бизнес-аналитик. Человек, который смотрит на задачи как требования к ИТ проекту через оптимизацию бизнес-процессов. И помимо того, что у нас появляется описание процессов, плюсом в регламенте относительно содержания функциональных требований является значимый раздел: список организационных изменений. Помимо подстройки ИТ-системы под измененные процессы мы должны эти процессы изменить и подготовить к автоматизации. А рамках раздела «организационные изменения» может быть выделение новых должностей, проведение кадровых перестановок, подбор новых людей, изменение системы мотивации и т.д. Т.е. большой организационный пласт, который будет поддерживать такую ИТ-систему.

Очевидно, что у людей, которые сталкиваются с такой задачей, может возникнуть вопрос: а как же будет выглядеть итоговый документ и чем он будет наполнен? Где можно посмотреть примеры?

Безусловно, самый популярный вопрос: а как это выглядит у вас? Здесь два момента.
Первый: когда мы подготавливаем эти документы, у нас есть определенный шаблон. Но шаблон – это скорее «пустографка». А просто показать «пустографку» – не информативно.
Второй вариант, что мы потенциально можем показать – это какие-то примеры документов, которые есть у клиентов. Но мы не можем показать сами оригиналы, потому что это чья-то интеллектуальная собственность. И принадлежит она тем, кто заплатил за подготовку.

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

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