 |
Способ реализации программного продукта является системно структурированным подходом к эффективной интеграции программного обеспечения обслуживания на основе или компоненты в рабочий процесс организационной структуры или индивидуальный конечного пользователь.
В этой статье основное внимание уделяется моделированию процессов (моделирование процессов ) реализации «большого» (объясняется различиями в сложности) программного продукта , используя в качестве основного примера реализацию систем планирования ресурсов предприятия .
Обзор
Метод внедрения программного обеспечения продукта - это план, позволяющий пользователям и / или организациям работать с конкретным программным продуктом.
Метод представляет собой набор правил и представлений для решения наиболее распространенных проблем, возникающих при внедрении программного продукта: согласование бизнеса с точки зрения организации и принятие с точки зрения человека.
Внедрение программного продукта в качестве последнего звена в цепочке развертывания производства программного обеспечения с финансовой точки зрения является серьезной проблемой.
Утверждается, что на реализацию (продукта) программного обеспечения уходит до 1/3 бюджета покупки программного обеспечения (больше, чем требования к оборудованию и программному обеспечению вместе взятые).
Различия в сложности реализации
Сложность внедрения программного обеспечения продукта различается по нескольким вопросам. Примеры: количество конечных пользователей, которые будут использовать программное обеспечение продукта, влияние, которое реализация оказывает на изменения задач и обязанностей конечного пользователя, культура и целостность организации, в которой будет использоваться программное обеспечение, и бюджет, доступный для приобретения программного обеспечения продукта.
Как правило, различия определяются по шкале размера (больше, меньше, больше, меньше). Примером программного продукта «меньшего размера» является реализация офисного пакета. Однако в организации может быть много конечных пользователей, влияние на задачи и обязанности конечных пользователей не будет слишком сильным, поскольку ежедневный рабочий процесс конечного пользователя существенно не меняется. Примером «более крупного» программного продукта является реализация системы планирования ресурсов предприятия . Внедрение требует глубокого понимания архитектуры организации, а также самого продукта, прежде чем его можно будет согласовать. Далее, использование ERP-системы требует гораздо большей отдачи от конечных пользователей, поскольку новые задачи и обязанности будут либо создаваться, либо переноситься.
Примеры других «более крупных» программных продуктов:
- Программное обеспечение для планирования ресурсов предприятия
- Программное обеспечение для управления взаимоотношениями с клиентами
- Программное обеспечение системы управления контентом
- Системы управления человеческими ресурсами
- Программное обеспечение для управления цепочкой поставок
Настройка программного обеспечения и редизайн бизнес-процессов
Моделирование процесса, используемое для согласования программного обеспечения продукта и организационных структур, связано с серьезной проблемой, когда делается вывод о том, что программное обеспечение продукта и организационная структура недостаточно хорошо согласованы для внедрения программного обеспечения. В этом случае возможны две альтернативы: настройка программного обеспечения или изменение организационной структуры, то есть бизнес-процессов.
Настройка программного обеспечения фактически превращает программное обеспечение продукта в программное обеспечение, разработанное специально для вас, поскольку идея стандартизованного программного обеспечения больше не применяется. Это может привести к потере поддержки программного обеспечения и необходимости получения консультационных услуг при возникновении проблем при использовании программного обеспечения. Однако настройка приводит к ситуации, когда целостность организации не регулируется, что оказывает меньшее давление на конечных пользователей, поскольку требуется меньше изменений или сдвигов в рабочих процессах. Этот факт может положительно повлиять на принятие любого нового используемого программного приложения (продукта) и, таким образом, может сократить время внедрения и бюджет на мягкой стороне бюджета внедрения.
Перепроектирование бизнес-процессов более разумно, поскольку вызывает сопротивление при использовании программного обеспечения продукта, поскольку измененные бизнес-процессы изменяют задачи и обязанности конечных пользователей программного обеспечения продукта. Однако, хотя программное обеспечение продукта не изменяется, возможны более качественные уровни поддержки, обучения и обслуживания ... потому что поддержка была создана для конкретной целостности программного обеспечения.
Рамки реализации
Руководящий принцип против профессии
Другой вопрос, связанный с процессом внедрения программного обеспечения продукта, - это выбор или, собственно говоря, вопрос, в какой степени следует использовать метод реализации.
С одной стороны, методы реализации могут использоваться в качестве руководящего принципа, указывая на то, что метод служит общим представлением о том, как должна проходить фаза реализации любого проекта. Этот выбор оставляет больше места для ситуационных факторов, которые не учитываются в выбранном методе, но приведут к двусмысленности, когда возникают вопросы при выполнении процесса реализации.
С другой стороны, методы можно использовать как профессию, а это означает, что к методу следует относиться строго, и использование метода должно быть профессией, а не руководящим принципом. Это представление очень полезно, если процесс реализации очень сложен и очень зависит от точных действий. Организационный менеджмент и менеджмент качества примут эту точку зрения, поскольку строгое использование любого метода приводит к большей ясности на организационном уровне. Однако управление изменениями может указывать на то, что большая гибкость метода реализации оставляет больше места для мягкой стороны процессов реализации.
Рамки реализации
Помимо методов реализации, служащих набором правил для реализации определенного продукта или услуги, рамки реализации служат в качестве управляемой структуры проекта для определения фазы реализации по времени, бюджету и качеству.
Несколько методов управления проектами могут служить основой для реализации метода реализации. Поскольку эта статья посвящена внедрению программного обеспечения продукта, лучшими методами управления проектами, подходящими для поддержки фазы внедрения, являются методы управления проектами, которые также сосредоточены на самом программном обеспечении и информационных системах. Применимость использования фреймворка для методов реализации поясняется на примерах использования метода разработки динамических и статических систем (DSDM) и Prince2 в качестве фреймворков методов управления проектами.
DSDM
Сила метода разработки динамических систем заключается в том, что в этом методе используются принципы итерации и возрастающей ценности, что означает, что проекты выполняются в повторяющихся фазах, где каждая фаза увеличивает ценность проекта. Таким образом, этапы реализации могут выполняться поэтапно и повышать ценность важных аспектов проекта, таких как степень принятия, осведомленность и навыки на каждом этапе [F. Фон Мейенфельдт, Управление проектами Basiskennis, Academic Service, 1999]. Помимо управления случайной областью, приращения также можно использовать в области моделирования процесса на этапах реализации. Использование приращений может привести в соответствие модели процессов бизнес-архитектуры и программного обеспечения продукта, поскольку добавление большего количества деталей на каждом приращении фазы сближает обе модели. DSDM также имеет место для поэтапного обучения, документирования и проверки.
Prince2
Как и в случае с DSDM, метод Prince2 признает реализацию как фазу внутри метода. Prince2 состоит из набора процессов, 3 из которых специально предназначены для реализации. Процессы контроля этапа, управления поставкой продукта и управления границами этапов позволяют детализировать процесс внедрения с такими факторами, как время и качество. Метод Prince2 может выполняться итеративно, но он также подходит для прямого выполнения процессов.
Прибыль от любого процесса внедрения, заключенного в структуру управления проектами, составляет:
Ясность
Схема реализации предлагает подробный процесс с такими факторами, как время, качество, бюджет и осуществимость.
Итеративный, инкрементный подход
Как объяснялось, возможность итеративно выполнять различные фазы процесса реализации позволяет выполнять процесс путем постепенного согласования продукта, который будет реализован, с конечным пользователем (организацией).
Встроенные и общие методы
Один из способов внедрения программного обеспечения продукта - использование встроенного метода или модели. Встроенные модели являются частью вспомогательных материалов (см .: определение программного обеспечения продукта ), которые поставляются с программным пакетом.
Реализация программного продукта с использованием встроенной модели подразумевает не только то, что модель (в большинстве случаев) может использоваться только с конкретным программным продуктом, но также то, что продукт может или должен быть реализован только с использованием модели. Таким образом, встроенные методы можно рассматривать как очень специфические способы реализации программного обеспечения продукта.
Примеры программных продуктов со встроенным методом:
Внедрение SAP ( SAP R / 3 ) с использованием встроенной модели ARIS.
Внедрение системы Baan ERP с использованием динамического моделирования предприятия (DEM).
Внедрение Oracle E-Business Suite с использованием метода реализации приложений Oracle (AIM).
Общие методы реализации предназначены не для конкретного программного продукта, а для общего использования при реализации продуктовых программных продуктов. Это использование будет подробно описано на примере реализации программного обеспечения продукта с использованием методологии объектного процесса . Эта методология очень полезна, например, в моделировании ERP : моделировании систем ERP с целью внедрения его в организационную структуру.
Оценки
Использование встроенного метода дает возможность, которую метод разработан, для реализации программного продукта, с которым поставляется метод. Это предполагает менее сложное использование метода и больше возможностей поддержки. Очевидно, что отрицательный аспект встроенного метода заключается в том, что он может использоваться только для определенного программного обеспечения продукта. Инженеры и консультанты, работающие с несколькими программными продуктами, могли бы больше использовать общий метод, чтобы иметь только один способ работы.
Использование универсального метода, такого как моделирование ERP, дает возможность использовать этот метод для нескольких систем ERP. В отличие от встроенных методов, использование общих методов позволяет инженерам и консультантам, работающим в компании, где несколько систем ERP внедрено в организациях клиентов, адаптироваться к одному конкретному методу работы, вместо того, чтобы приобретать навыки для нескольких встроенных моделей. Однако у общих методов отсутствует тот недостаток, что проекты внедрения могут стать слишком ситуативными, что приведет к трудностям и сложности в выполнении процесса моделирования, поскольку будет доступна меньшая поддержка.
