Ogrik.ru

5.3.2.Анализ и концептуальное проектирование

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

Поэтому, по сути, эта фаза – продолжение предпроектных работ, но уже на возмездной основе (то есть оплачиваемых), с выделенным сроком, сформированной проектной командой (и выделением на эти работы сотрудников и их времени со стороны заказчика). Может быть оформлена как отдельный мини-проект с отдельным договором, например на аудит ИТ-инфраструктуры, бизнес-процессов и формирование детальных требований к ERP-системе.

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

Нужно отметить, что на данный момент заказчик еще может не определиться с выбором самой системы автоматизации и такой анализ и формулирование детальных требований могут быть совмещены с анализом их покрытия той или иной системой или отраслевым решением внутри единой платформы. Например, на данный момент может быть еще не ясно, что лучше подходит для нужд заказчика: «1С:ERP Управление предприятием» или «1С:Управление холдингом».

Документооборот и результаты фазы:

Результат (документ)	Рабочий/отчетный	Ответственный за создание
Актуализированная спецификация требований	Рабочий	РП заказчика и РП исполнителя
Внутренние документы для анализа (отчеты, регламенты, базы данных)	Рабочий	РП заказчика
Развернутая 1C:ERP с прототипом	Система	РП исполнителя
Протоколы совещаний	Рабочий	РП исполнителя
Концептуальный проект (отчет об обследовании)	Отчетный	РП исполнителя
Презентации концепций	Рабочий	РП исполнителя, консультант, системный архитектор
Устав проекта (обновление)	Отчетный	РП исполнителя
План-график проекта (уточненный)	Отчетный	РП исполнителя
Договор на этап проекта (или доп. соглашение на уточнение срока и бюджетов)	Отчетный	РП исполнителя
Акт выполненных работ по фазе	Отчетный	РП исполнителя

• 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. Список использованной литературы

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