Начну с примера. В компании «А» юристы тратили очень много времени на согласование договорных документов. Чтобы упростить и ускорить этот процесс, руководитель поставил IT-специалисту задачу — найти подходящее ПО для выстраивания процессов и перевода документов в электронный вид. IT-специалист честно выполнил поручение — нашел платформу, презентовал руководителю, тот согласился, оплатил покупку и внедрение. Но спустя три года воз и ныне там — юристы по-прежнему используют бумагу.
Системный администратор халатно отнесся к поиску подходящей системы? Нет, он просто ни разу не посоветовался с будущими основными пользователями, не узнал тонкости их работы, а ориентировался исключительно на свои знания. Такие кейсы не редкость.
Почему важно собрать требования? Ответ прост: чтобы в результате получить ту систему, которая действительно решит проблемы будущих пользователей. В конечном итоге и компания, и поставщик продукта заинтересованы в том, чтобы покупка принесла положительный эффект и экономию ресурсов. Для этого стоит действовать поступательно.
Шаг №1. Определите основной класс системы
Выделяют разные классы систем, перечислю основные:
- ERP – планирование ресурсов предприятия;
- ECM – управление контентом предприятия;
- BPM – управление бизнес-процессами;
- CRM – управление взаимоотношениями с клиентами;
- HRM – управление персоналом.
Сегодня границы классов размываются, потому что предприятиям нужно закрывать разные задачи, но не существует идеального одного единственного ИТ-продукта, который будет одинаково хорошо отвечать всем потребностям бизнеса. Зато вы запросто найдете программы, которые имеют основное направление, и могут частично восполнить функциональность других классов. Поэтому, чтобы закрыть все требования компании, покупают несколько систем и настраивают между ними интеграцию.
Чтобы определиться с основным классом, необходимо ответить на вопрос – какое главное действие система должна выполнять?
- Если это работа с документами и задачами – ECM + BPM.
- Если контроль продаж – CRM.
- Если подсчет количества ресурсов (материалов, финансов и т. д.) – ERP.
Шаг №2. Выделите ведущих бизнес-пользователей системы
Для кого вы выбираете систему? Выпишите список заинтересованных сотрудников, которые будут ею пользоваться. Эта информация пригодится на этапах определения масштаба проекта и настройки системы.
Рис.1. Пример описания степени вовлеченности в систему.
Шаг №3. Соберите «хотелки» будущих пользователей и руководителя
Чтобы продукт был востребован, важно определить, какие проблемы и запросы бизнеса он должен решать.
Есть несколько уровней требований: основные, вспомогательные и дополнительные.
Сначала найдите ответы на вопросы:
- «Зачем это нужно?»
- «Почему это важно?»
- «На что это влияет?».
Ответить на них могут только заинтересованные стороны, которых мы определили в шаге №2. Информация от них поможет определить основные требования к ПО.
«Заинтересованных сторон много, а я – один», — подумаете вы. Не пугайтесь, все, что нужно сделать сейчас – задать правильные вопросы каждой заинтересованной стороне и свести ответы в один документ. Затем сформулируйте задачу на описание требований к системе, отправьте ее главному представителю заинтересованной стороны (вероятно, это будет руководитель отдела), обозначьте срок предоставления ответа.
Шаг №4. Приоритизируйте требования
Соберите совещание, где будут присутствовать:
- представитель каждого отдела из числа основных пользователей;
- представитель из группы «контролеров».
Расставить приоритеты будет легче, если заранее выбрать метод. По моему опыту один из самых эффективных — MoSCoW, где каждая заглавная буква — это оценка требования:
|
Наименование |
Описание термина |
Пример |
|
|
M |
Must Have / должен иметь |
То, без чего система будет бесполезна. Это фундаментальные требования к функциональности, которые будут полезны нескольким заинтересованным сторонам |
Система должна иметь возможность подписывать документы ПЭП и УКЭП. |
|
o |
- |
||
|
S |
Should Have / следовало бы иметь |
Не самые важные требования. Без их реализации компания жить может, но работать в системе не так комфортно. |
Для договорных и закрывающих документов, система должна иметь интеграцию с Диадок в режиме одного окна. |
|
C |
Could Have / может иметь |
Желательные требования. Можно их реализовать, если есть свободное время и бюджет. Обычно эти требования оставляют на развитие. |
В системе должна быть возможность массовой загрузки приложений к документу. |
|
o |
- |
||
|
W |
Would Like / хотелось бы |
Косметические требования-хотелки, которые можно проигнорировать без вреда для эффективности системы. Обычно эти требования реализуют, когда есть «лишние» деньги на реализацию. При реализации нет четких сроков. |
Система должна с помощью искусственного интеллекта автоматически создавать поручение и выделять ответственного. |
Определение важности любого критерия субъективно. Поэтому приоритеты обсуждать необходимо с коллегами, для которых это требование реализуется. Во время совещания нужно оценить не только то, что система должна уметь, но и то, какой результат ожидается от нее.
Шаг №5. Выберите систему
Шаг последний, но очень важный. Оцените сроки и бюджет, которыми располагаете, и сопоставьте с характеристиками системы. Насколько она готова к быстрому внедрению и старту эксплуатации.
1. Для компаний среднего и малого бизнеса всегда лучше рассматривать программные продукты, не требующие доработок.
Почему это важно? Вы определили требования к системе «здесь и сейчас». Скорее всего, в них не учтено поведение системы в нетиповых ситуациях, которые проявляются редко или пока не случались с вами. Это нормально – нельзя учесть сразу все, и это не ваша работа. В уже готовом решении предусмотрено, как оно будет работать в разных ситуациях. Это возможно благодаря большому штату аналитиков, опыту работы с клиентами и отслеживанию изменений в законодательстве. Каждая новая версия готового продукта расширяет его возможности. В этом случае вам не нужно тратить время на анализ и дополнительный бюджет на реализацию.
2. Спросите у поставщика, сколько времени требуется на внедрение системы, и что может повлиять на сроки.
Уточните, что может пойти не так, и как это повлияет на скорость работ? Кто предупрежден – тот вооружен. Выбрать ПО – половина дела, дальше его нужно подготовить к использованию. Поставщики обычно предлагают ряд услуг, которые помогают внедрить систему в определенный срок. Он может быть разным: от 5 дней до нескольких месяцев. Если вы выберите готовую систему, которая уже в базовой комплектации закрывает ваши основные требования, то внедрение пройдет быстрее.
3. Определите бюджет, который вы готовы потратить на само ПО, его внедрение и сопровождение.
В зависимости от варианта размещения (в облаке или на собственном сервере компании) периодичность оплат может меняться. Определите сумму, которую готовы потратить на старте.
Если понимаете, что внедрять самостоятельно будет сложно – сразу поднимите вопрос о выделении бюджета на услуги. Иногда может понадобиться весь спектр, иногда бывает достаточно просто обучения по администрированию. На свой «страх и риск» можно проконсультироваться с менеджером.
Сразу уточните, сколько стоит подписка на обновление и новые версии ПО. Эта информация даст понимание, какой бюджет закладывать на следующий год. Система – живой организм. Если не обновлять ее годами, то она умрет. За возможность получить обновления просят деньги.
А как вы выбирали систему в компанию? Расскажите в комментариях.
Читайте также:
Это практически типичная ситуация. Не столько от увеличения масштабов зависит, сколько от продолжительности жизни компании.
Лет 30 назад у меня была попытка устроится в США, как специалисту в одной из очень старых баз данных.
Работал в Directum в одной очень крупной компании. Достойный надо сказать продукт. Ну это так, к слову. :))!