Начну с примера. В компании «А» юристы тратили очень много времени на согласование договорных документов. Чтобы упростить и ускорить этот процесс, руководитель поставил 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. Определите бюджет, который вы готовы потратить на само ПО, его внедрение и сопровождение.
В зависимости от варианта размещения (в облаке или на собственном сервере компании) периодичность оплат может меняться. Определите сумму, которую готовы потратить на старте.
Если понимаете, что внедрять самостоятельно будет сложно – сразу поднимите вопрос о выделении бюджета на услуги. Иногда может понадобиться весь спектр, иногда бывает достаточно просто обучения по администрированию. На свой «страх и риск» можно проконсультироваться с менеджером.
Сразу уточните, сколько стоит подписка на обновление и новые версии ПО. Эта информация даст понимание, какой бюджет закладывать на следующий год. Система – живой организм. Если не обновлять ее годами, то она умрет. За возможность получить обновления просят деньги.
А как вы выбирали систему в компанию? Расскажите в комментариях.
Читайте также:
Лайк.
Подписываюсь под каждым пунктом!
Спасибо автору.
Добавил бы, что в идеале руководители должны быть не контролерами, а пользователями. Для этого придуманы информационные панели (dashbords).
Странно, но в таком случае внедрение идет гораздо легче )))
Все по полочкам. Замечательная статья!
Смешанные чувства.
Есть классические книги по сбору требований при разработке ПО и создании систем. Есть международные и национальные стандарты с перечнем соответствующих документов и их содержанием. Есть своды знаний в этих областях, включая BABoK и PMBoK. Есть лучшие практики.
Почему бы всё это не вспомнить. Но в статье нет ни одной ссылки или примера.
К слову, на Шаге 5 смешиваются работы разных людей в самых разных жанрах. И практически каждый абзац в этой части публикации можно и нужно обсуждать намного подробнее - там слишком много открытых вопросов. Рекомендации "всегда лучше" не имеют смысла и противоречат другим тезисам публикации.
Что касается «хотелок», то это стандартная процедура, которая заканчивается составлением ТЕХНИЧЕСКОГО ЗАДАНИЯ. После чего наступает самое главное, как под него выбрать ПО. Здесь только два варианта. Первый – подбором будет заниматься местный персонал ИТ, или ТЗ направить в несколько специализированных компаний. Не думаю, что местные ребята знают все тонкости различных ПО и скорее всего, ошибутся в выборе. Во втором случае – каждая ИТ компания будет хвалить свой продукт и заверять, что ОНА все МОЖЕТ (какой ценой они не уточняют). И вот тут сложный вопрос: КАК ПОСУПИТЬ и КТО возьмет на себя ответственность за принимаемое решение. Ответа нет.
Как бы да, все верно. Но только ИТ - система выбирается для решения задач бизнеса, а не для удобства отдельных пользователей. Поэтому со стороны владельца так же как со стороны руководителей подразделений должны быть усилия по преодолению сопротивления сотрудников. Сопротивление будет всегда хотя бы из категории "хочу зелёные кнопки вместо красных". Должна быть построена карта целей компании, в которой должно быть указано, для достижения каких целей внедряется ИТ-система. Карта целей строится на стратегической сессии с руководством компании. Для подготовки стратсессии проводится диагностика процессов компании, готовятся шаблоны документов. Если мы хотим получить KPI для карты целей и регулярного сравнения план/факт нужно строить финмодель. А чтобы определить границы ответственности сотрудников, загрузку и временные нормативы строятся бизнес - процессы в специальной системе типа Business Studio. Хотелки отдельных пользователей обсуждаются с их руководителями на последнем этапе и принимаются к сведению. Они все равно не помогут в выборе ИТ системы потому что не знают стратегические задачи компании и возможности существующих на рынке решений.
Я бы еще добавил возможность развития системы.
Ну и в список критериев политику развития от поставщика.
Одно дело, когда за каждый чих приходится платить и биться и другое когда поставщик раз в полгода выпускает обновление, доступное по подписке.
Добавлю еще своё любимое - статья очень хорошо написана, структурированно и с достаточным раскрытием информации, и нет вопросов - что хотел сказать автор. Технически с любым содержанием всегда может кто-то не соглашаться, но вот изложено все отлично.
В одной статье невозможно дать советы на все случаи в жизни. Внедрение - процесс непростой.
Алина очень доходчиво поделилась своими предложениями. Я работал с выбором Директума (если я правильно понял).
Но всё-таки эти советы требуют обдумавания и уточнения
Начало статьи:
Если в компании А целый юридический отдел, значит компания большая. Юристы - ребята сложные для внедрения, знаю это по опыту. Обратите внимание, что и у нас на форуме все юридические статьи остались без комментариев авторов. Абсолютно все! И директор поручает выбирать систему и внедрять ИТ-специалисту? Директор просто отмахнулся от этого.
Но по одной из версий крайним оказался системный администратор. Занавес. Юристы же получили премию, да? Как говорит старая айтишная пословица, во всём виноваты евреи и программисты.
А чтоб зубы почистить вы зовёте врача?
Описанное мне почему-то напомниет выбор спутника/спутницы жизни: "Чтоб не пил, не курил, чтоб цветы всегда дарил". Но так не бывает. Так не будет. Так нельзя с ИТ-системами.
Чтоб долго не растекаться напишу, что очень согласен с коллегами:
Но если директор даёт поручение системному администратору выбрать и внедрить систему, значит что-то у директора не так в организации. Я так думаю, в компании сисадмина обзывают "компьютерщиком". Ясно же, что врач, это не врач, а лечильщик.
Кстати, я писал несколько месяцев назад:
https://www.e-xecutive.ru/management/itforbusiness/1997296-8-vrednyh-sovetov-po-vnedreniu-sistemy-elektronnogo-dokumentooborota