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