Что такое требования и для чего они нужны

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

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

Как начать формулировать требования

Для начала давайте придумаем пример, на котором будем рассматривать формулирование требований — пусть это будет заключение договора с клиентом.

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

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

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

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

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

Пример:

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

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

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

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

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

Например:

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

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

Третье — мы хотим сделать работу сотрудников более размеренной». 

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

Выделение ролей и бизнес смысла ролей

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

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

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

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

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

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

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

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

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

Выделение периферийных систем

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

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

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

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

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

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

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

Что будет, если составить требования неправильно

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

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

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

На чем не стоит зацикливаться

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

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

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

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

Как мы помогаем формировать требования к системе в Бипиуме

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

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

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

Краткое резюме

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

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

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

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

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

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

А еще вы можете обратиться к нам и мы поможем вам сформировать требования.