Серия программного обеспечения ERP:разработка требований пользователей

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

Две категории требований

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

Требования будущего государства представляют, как компания планирует работать в будущем и использовать программное обеспечение для поддержки своего функционирования. Будущее следует определять через 5-7 лет. Хотя ни одна компания не может точно предсказать, как они будут работать через семь лет, компания может представить себе, как она планирует вести бизнес и какие типы программного обеспечения и аппаратных технологий потребуются для реализации своей долгосрочной стратегии.

Карты бизнес-процессов

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

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

• CRM
• Ценовое предложение и ввод заказов на продажу
• Служба поддержки клиентов
• Инжиниринг - для поддержки предложения и поддержки производства.
• Цепочка поставок / закупки
• Управление складом / Управление запасами / Получение
• Планирование и составление графиков
• Заказы на выполнение работ и отчеты по цеху
• Доставка
• Качество
• Бухгалтерский учет - кредиторская задолженность и выплаты наличными
• Бухгалтерский учет - Выставление счетов / Дебиторская задолженность / Расчет наличных
• Бухгалтерский учет - Главная книга

Карты бизнес-процессов должны включать все входы и выходы, относящиеся к бизнес-процессам текущего и будущего состояния. Эти действия следует «наложить» на индикаторы того, какое программное обеспечение используется для поддержки текущего действия. Примерами могут быть действия, использующие текущую систему ERP, действия, использующие MS Excel или базы данных Access, или действия, выполняемые вручную.

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

Контрольные списки

Контрольные списки использовались для выбора программного обеспечения на протяжении десятилетий. Контрольные списки обычно основаны на знаниях третьей стороны, которая перечисляет буквально сотни или тысячи функциональных требований, сгруппированных аналогично приведенному выше списку. Многие из этих контрольных списков связаны с базами данных «да / нет» ряда поставщиков программного обеспечения. Заполнив контрольный список, пользователь получит список поставщиков ERP, которые наиболее способны удовлетворить потребности пользователя.

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

Требуется пояснение, предназначено ли конкретное решение для компании, чей объем продаж составляет от 5 до 25 миллионов долларов, или для компании, чей объем продаж составляет от 250 до 500 миллионов долларов. Ярким примером является то, что SAP и Oracle предоставляют функциональные возможности для поддержки указанных выше областей бизнес-процессов, как и JobBOSS и E2 (популярные решения для рабочих мест). Необходимо соответствие между объемом решения, требованиями и бюджетом (ценностным предложением), а также отраслью и базовой структурой производства между дискретным производством и непрерывным производством.

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

Повествования

Автор предпочитает описательный документ, который объясняет процессы текущего состояния и обсуждает потребности будущего состояния. Опрашивая людей, участвующих в бизнес-процессе, можно создать повествования, рассказывающие о том, как бизнес работает сегодня и как он хочет работать в будущем. Может быть представлен надежный уровень детализации, который позволит поставщику полностью понять бизнес. Рассказы также могут быть дополнены тем, чем занимается бизнес, почему компания ищет новое программное обеспечение (ценностное предложение) и какие технологии используются в настоящее время.

Что хочет проверить продавец

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

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

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

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