Ogrik.ru

6.3.Приоритизация требований

В главе 2 рассматривались вопросы сбора требований и fit-gap анализа по ним. На фазе анализа пересматриваются изначальные приоритеты по требованиям уже с учетом возможностей ERP-системы и разумной компоновки границ проекта по срокам и бюджету.

Для приоритизации можно воспользоваться методом MoSCoW (легко запомнить и понять). Метод получил свое название от акронима, образованного следующими классификациями приоритета (буква «o» добавлена для созвучности):

• Must have – обязательно должно быть (жизненно необходимые требования, без чего не будет работать);
• Should have – следовало бы иметь (обязательные требования, без чего сложно обойтись);
• Could have – может быть (стоит сделать для удобства работы);
• Would like – хотелось бы иметь (можно не делать, «бантики»).

Вся эта методика прекрасно иллюстрируется на примере шариковой ручки, состоящей:

• из стержня – без него никак нельзя что-то написать (must have);
• корпуса – писать одним стержнем крайне неудобно, нужная вещь (should have);
• зажима на корпусе, автомата убирания стержня – полезные для удобства работы опции, но без них уже можно пользоваться инструментом для письма (could have);
• логотипа и фонарика в торце – на функции работы шариковой ручки никак не влияют, просто опции (would like).

Рис. 6.2. Приоритизация MoSCoW на примере шариковой ручки

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

И тут исполнителю тоже нельзя занимать позицию «как скажете, так и сделаем», нужно все время проверять полученный пул задач на реализуемость и сочетаемость между собой. Например, нельзя сделать какое-то требование с приоритетом must have, если оно делается поверх функциональности, помеченной would like и в этот этап вообще не входящей.

В торге и спорах за приоритеты хорошо помогают оценки реализации (время и стоимость) этих требований. Они сразу отрезвляют поток пожеланий и расставляют все точки над «i»: когда что-то по факту не нужное (но очень желаемое – would like) стоит дорого, оно сразу становится некритичным. Как оценивать сроки и бюджет проекта, рассмотрим в следующей главе.

• 1. Обложка
• 2. Титульный лист
• 3. Выходные данные
• 4. Введение
• 5. Принятые термины и сокращения
• 6. Глава 1. Что такое ERP-система и зачем она компании
• 7. 1.2.Отличие ERP-системы от учетной бухгалтерской системы
• 8. 1.3.Зачем ERP-система компании
• 9. 1.4.Затраты на владение системой (стоимость эксплуатации)
• 10. 1.4.1.Облачные сервисы как путь снижения затрат
• 11. Глава 2. Как выбрать ERP-систему
• 12. 2.2.Тендер и участие в нем
• 13. 2.2.2.Со стороны исполнителя
• 14. 2.3.Fit-gap анализ разных систем
• 15. 2.4.ИТ-ландшафт текущий и перспективный
• 16. 2.5.Нагрузочные тесты и выбор «железа»
• 17. 2.6.Окупаемость и обоснование затрат на автоматизацию
• 18. Глава 3. Как внедрять ERP-систему
• 19. 3.1.1.Agile-методологии
• 20. 3.1.2.Серия стандартов ISO
• 21. 3.1.3.ГОСТ 34
• 22. 3.1.4.PMBOK
• 23. 3.1.5.Технологии управления проектами фирмы «1С»
• 24. 3.2.Введение в терминологию
• 25. 3.2.1.Проектный треугольник
• 26. 3.3.Реинжиниринг бизнес-процессов
• 27. 3.4.Какие подсистемы в какую очередь внедрять
• 28. Глава 4. Кто участвует в проекте внедрения
• 29. 4.1.1.Управляющий комитет
• 30. 4.1.2.Проектная команда исполнителя
• 31. 4.1.3.Рабочая группа со стороны заказчика
• 32. 4.2.Мотивация участников проекта внедрения
• 33. 4.2.2.Модели мотивации
• 34. 4.3.Коммуникация и конфликты
• 35. 4.3.1.Удаленное взаимодействие
• 36. 4.3.2.Командообразование
• 37. 4.3.3.Управление конфликтами
• 38. Глава 5. Этапы и документация проекта
• 39. 5.2.Документация проекта
• 40. 5.3.Фазы проекта
• 41. 5.3.2.Анализ и концептуальное проектирование
• 42. 5.3.3.Дизайн архитектуры системы
• 43. 5.3.4.Разработка
• 44. 5.3.5.Опытная эксплуатация
• 45. 5.3.6.Ввод в промышленную эксплуатацию
• 46. 5.3.7.Закрытие проекта
• 47. Глава 6. Что анализировать и как настроить прототип системы
• 48. 6.2.Готовим отчет
• 49. 6.3.Приоритизация требований
• 50. 6.4.Описание бизнес-процессов
• 51. 6.4.1.Функциональные блок-схемы
• 52. 6.4.2.IDEF0
• 53. 6.4.3.EPC
• 54. 6.4.4.BPMN
• 55. 6.4.5.Особенности описания бизнес-процессов
• 56. 6.5.Прототип и его демонстрация
• 57. Глава 7. Как оценить срок и бюджет проекта
• 58. 7.2.Методы оценки трудозатрат
• 59. 7.2.2.Анализ предложений исполнителей
• 60. 7.2.3.Оценка «снизу вверх»
• 61. 7.2.4.Оценка «сверху вниз»
• 62. 7.2.5.Экспертная оценка
• 63. 7.2.6.Параметрическая оценка
• 64. 7.2.7.Оценка по трем точкам (метод PERT)
• 65. 7.3.Мифический человеко-час
• 66. 7.4.Расчет себестоимости человеко-часа
• 67. 7.5.Как получить итоговый срок проекта
• 68. Глава 8. Риски проекта и управление ими
• 69. 8.2.Какие риски бывают в проекте внедрения ERP-системы
• 70. 8.3.Профилактика и как бороться с проявлениями рисков
• 71. 8.4.Когда риски можно игнорировать
• 72. 8.5.Процедура управления рисками в проекте внедрения ERP-системы
• 73. Глава 9. Как пережить фазы разработки и опытной эксплуатации
• 74. 9.2.Стандарты разработки
• 75. 9.3.Тестирование
• 76. 9.4.Готовимся к обучению пользователей
• 77. 9.5.Опытная эксплуатация
• 78. 9.6.Ведем список запросов на изменение
• 79. Глава 10. Запуск системы и что дальше
• 80. 10.2.Система продолжает работать – сопровождение корпоративной системы
• 81. Заключение
• 82. Список использованной литературы

Показать оглавление Скрыть оглавление