Как правильно сформировать требования к ИТ-системе

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

За 7 лет разработки и внедрения индивидуальных IT-систем на нашей платформе Бипиум мы столкнулись с множеством крупных и не очень крупных предприятий. Каждое находилось на определенном этапе развития цифровой грамотности. Кто-то формулирует требования профессионально, у кого-то получается не очень профессионально. Мы хотим помочь вторым разобраться в теме и научить их понимать цель внедрения IT-системы.

Статья большая, поэтому держите оглавление:

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

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

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

Рассмотрим на примере процесса заключения договора с клиентом.

Шаг №1

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

Используя наш пример с заключением договора, можно описать следующее:

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

Автоматизируемая деятельность выглядит следующим образом: менеджер формирует и подписывает с заказчиком договор, передает договор в бухгалтерию для выставления счета».

Шаг №2

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

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

Вторая проблема — менеджеры долго формируют данный договор, подставляя данные во все нужные поля.

Третья проблема — договоры долго доходят до бухгалтерии, из-за этого процесс получения денег сильно затягивается.

Четвертая проблема — менеджеры приходят/звонят в бухгалтерию, чтобы уточнить статус договора и денег, а это отвлекает бухгалтеров и сильно замедляет работу».

Шаг №3

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

Например:

«Мы хотим организовать учет всех договоров, чтобы они не терялись.

Мы хотим ускорить процесс формирования договора, в идеале — формировать его автоматически.

Мы хотим прогнозировать загруженность рабочего времени сотрудников».

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

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

Выделите всех участников процесса и определите, что они делают в бизнес-деятельности и что они будут делать в информационной системе. Бизнес-деяетельность — это фактические рабочие действия человека, «отправить документ», «подписать документ» и т.д.

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

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

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

В системе: не выполняет никаких операций

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

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

Бухгалтер. Ведет учет обязательств покупателей и перед покупателями.

В системе: меняет статус, отображающий состояние сделки, прикладывает к сделке документы — счета и акты.

С деятельностью и информационной системой связаны не только люди. С ней могут быть связаны еще и другие системы и сервисы.

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

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

Продолжая рассматривать наш пример, давайте опишем взаимодействия систем:

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

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

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

Если сформулируете требования некорректно или не полностью, то полученный вами продукт не будет соответствовать ожиданиям и вместо упрощения деятельности усложнит её.

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

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

Частая проблема при формулировании требований — погружение на уровень отдельных действий, внешнего вида или цвета кнопок в системе. Уделяя слишком много времени тому, как будет выглядеть та или иная кнопка, вы отдаляетесь от цели создания системы.

Всегда помните, что вы формулируете требования, а не пишите техническое задание по ГОСТу. Не надо писать слишком формальным языком, поскольку с требованиями будет знакомится такой же живой человек как и вы.

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

Другой проблемой может быть, когда вы совмещаете уровень «кнопочек» и максимально широкое описание функционала. Например, заказчик говорит, что хочет нажать на кнопку и «увидеть всё». Но он сам не понимает, что имеет в виду под этим «всё».

Процесс формирования требований можно разделить на несколько этапов:

1. Выяснить, для чего система и какие проблемы она должна решить.

2. Понять, кто и как в ней будет работать.

3. Сформулировать требования к интеграциям с другими системами.

4. Расписать все возможные пути развития событий.