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