Начну с примера. В компании «А» юристы тратили очень много времени на согласование договорных документов. Чтобы упростить и ускорить этот процесс, руководитель поставил 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. Определите бюджет, который вы готовы потратить на само ПО, его внедрение и сопровождение.
В зависимости от варианта размещения (в облаке или на собственном сервере компании) периодичность оплат может меняться. Определите сумму, которую готовы потратить на старте.
Если понимаете, что внедрять самостоятельно будет сложно – сразу поднимите вопрос о выделении бюджета на услуги. Иногда может понадобиться весь спектр, иногда бывает достаточно просто обучения по администрированию. На свой «страх и риск» можно проконсультироваться с менеджером.
Сразу уточните, сколько стоит подписка на обновление и новые версии ПО. Эта информация даст понимание, какой бюджет закладывать на следующий год. Система – живой организм. Если не обновлять ее годами, то она умрет. За возможность получить обновления просят деньги.
А как вы выбирали систему в компанию? Расскажите в комментариях.
Читайте также:
Абсолютно верно) Есть множество инструментов проверенных временем, чтобы собрать корректные требования и правильно их описать и приоритизировать.
В статье я написала самые минимальные шаги которые помогут небольшим и средним компаниям, у которых в штате нет бизнес-аналитика или ИТ специалиста. В малом бизнесе выбором системы часто занимаются рядовые сотрудники или руководители, у которых нет времени разбираться со всеми правилами сбора требований к системе. Но есть необходимость выбрать систему, которая зактроет основные потребности бизнеса.
Честно говоря, хотя автор очень убедительно описывает свой опыт, но у меня большие сомнения в правильности именно таого подхода. Да ещё и сисадмин в примере оказался крайним.
Ну только несколько вопросов:
- кто будет выбирать?
- кто будет внедрять?
- кто оценит бюджет?
- кто будет проводит приёмо-сдаточные испытания?
Вот на эти вопросы директор и сотрудники смогут ответить, а вот на вопросы деления на основные, вспомогательные и дополнительные функции вряд ли, кроме возможно гендира.Да и то не всегда.
Ну тогда уж проще оставить всё как есть и не заморачиваться внедрением. Если даже ИТ-специалиста нет. Оставьте электронную почту для официального обмена и парочку мессенджеров.
Этого хватит.
Николай, вы верно подметили, что я описывала свой опыт и опыт клиентов. К сожалению, очень часто Руководство именно "взваливает" ответственность на сотрудника по выбору корпоративной системы, хотя сотрудник может и не знать "а как выбрать то?". И в этот момент нет понимания какие вопросы кому задавать, т.к. это первый опыт (и ответы возможно не получит).
Статья написана именно для таких ситуаций, когда в небольшой компании нет бизнес-аналитика или опытного ИТ специалиста. А ответственное решение "какую систему покупаем" на плечах рядового сотрудника, который никогда не занимался подобным вопросом.
Для крупных и опытных компаний эти советы будут малы. Там уже иначе происходит процесс
Да, согласен. Вопросов много.
Какие-то из них решаются в формате закупок, какие-то - в формате проекта разработки, интеграции, внедрения и пр.. Там же, к примеру.и обсуждаются детали тестирования и приёмо-сдаточных испытаний (включая опытную эксплуатацию, если нужно).
При этом все возможные требования к системе нужно собирать в любом случае, хотя я бы это делал иначе.
Интересно, что годы идут, а проблемы выбора и внедрения ИТ-систем остаются. Не очень понял,для чего Алина вспомнила про различные классы систем, хотя речь ведёт явно про СЭД.
Можно прислушаться к этим советам, но это если совсем припёрло. Если масштабы компании резко выросли, а старые методы управления не позволяют быстро реагировать. Но тогда всё-таки надо начинать с обследования процессов. И лучше это доверить внешнему партнёру. Уж никак не сисадмину. Неудачный пример очень. И ни один руководитель отдела, даже если их собрать на совещание не выдаст требования, например, к информационной безопасности.
В принципе, как небольшая напоминалка статья будет полезной в начале пути, в перовй пробе своих сил в выборе и внедрении. Но коллеги абсолютно правы - книг и методик на эту тему полно.
Именно так.
Но всегда можно сузить тему и попробовать найти правильные ответы хотя бы на один или два вопроса из очень длинного списка.
Присоединяюсь и удваиваю ставку.
Да, жаль единственного исполнителя такой работы. Шансов у него немного:
Да уж. Подобных случаев великое множество. Многие гендиры считают, что за всё, что втыкается в розетку, отвечает "компьютерщик". Ну не бухгалтерии эже это поручать, не юристам!
И это пожалуй самая большая и катастрофическая ошибка при выборе и внедрении. Даже в малых компаниях.
Какие же из них Вы упомянули? Специалистам они известны, но, насколько я понимаю, Ваша статья расчитана на других категории читателей.
... Но некая система им нужна. Вряд ли компании среднего размера буквально всё делают вручную. Почему бы не пригласить тех, кто мог бы помочь, и избежать ситуации с первым блином.
Следующий вопрос: как эта система будет эксплуатироваться и развиваться, если в штате нет специалистов по IT ?
Да, знакомо.
Результаты могут быть значительно лучше и получены быстрее и дешевле, если эти работы будут поручены специалистам - начиная с формулирования и анализа требований и потребностей бизнеса с технической точки зрения..
Встречаются крупные и крупнейшие компани с "зоопарком" программ и мучаются, что с этим зоопарком делать. А начинали также со среднего и малого бизнеса, приобретая и внедряя программы - закрывающие текущие потребности и не задумываясь стратегически.
В статье нет ни слово о необходимости продумать на два-три года вперед и составить планируемую ИТ-архитектуру решений. Сэкономив на покупке сейчас, компании потом в разы переплачивают.
Поэтому вопрос цены надо рассматривать в контексте развития всего ИТ и советовать малому и среднему бизнесу - проконсультироваться и хотя бы базово прорисовать - продумать свое цифровое развитие.