Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Метод внедрения программного продукта – это систематически структурированный подход к эффективной интеграции программного сервиса или компонента в рабочий процесс организационной структуры или отдельного конечного пользователя. Данная статья посвящена моделированию процессов (Process Modeling) при внедрении масштабного (объясняется различиями в сложности) программного обеспечения, а в качестве основного примера для подробного рассмотрения используется внедрение систем планирования ресурсов предприятия.
A product software implementation method is a systematically structured approach to effectively integrate a software based service or component into the workflow of an organizational structure or an individual end user. This entry focuses on the process modeling (Process Modeling) side of the implementation of “large” (explained in complexity differences) product software, using the implementation of Enterprise Resource Planning systems as the main example to elaborate on.
Обзор
Метод внедрения программного продукта – это руководство, позволяющее пользователям и/или организациям начать работу с конкретным программным продуктом. Этот метод представляет собой набор правил и подходов для решения наиболее распространенных проблем, возникающих при внедрении: соответствие бизнес-целям с точки зрения организации и принятие пользователями. Внедрение программного продукта, как завершающий этап в цепочке создания программного обеспечения, является существенным вопросом с финансовой точки зрения. Утверждается, что на внедрение программного продукта может уходить до трети бюджета, выделенного на его приобретение (больше, чем на аппаратное и программное обеспечение вместе).
A product software implementation method is a blueprint to get users and/or organizations running with a specific software product. The method is a set of rules and views to cope with the most common issues that occur when implementing a software product: business alignment from the organizational view and acceptance from human view. The implementation of product software, as the final link in the deployment chain of software production, is in a financial perspective a major issue. It is stated that the implementation of (product) software consumes up to 1/3 of the budget of a software purchase (more than hardware and software requirements together).
Настройка программного обеспечения и перепроектирование бизнес-процессов
Моделирование процессов, используемое для согласования программного обеспечения продукта и организационных структур, сталкивается с важной проблемой: когда приходит к выводу, что программное обеспечение продукта и организационная структура недостаточно согласованы для успешной реализации. В этом случае возможны два варианта: адаптация программного обеспечения или перепроектирование организационной структуры, а следовательно, и бизнес-процессов. Адаптация программного обеспечения фактически превращает продукт в индивидуальное решение, поскольку концепция стандартизированного программного обеспечения становится неактуальной. Это может привести к прекращению поддержки программного обеспечения и необходимости привлечения консультантов при возникновении проблем в процессе его использования. Однако адаптация позволяет сохранить существующую организационную структуру, что снижает нагрузку на конечных пользователей, поскольку требует меньше изменений в рабочих процессах. Это может положительно повлиять на принятие нового программного обеспечения и, следовательно, сократить сроки и затраты на "мягкую" часть внедрения. Перепроектирование бизнес-процессов, напротив, чаще вызывает сопротивление при использовании программного обеспечения, поскольку изменения в бизнес-процессах влекут за собой изменения в задачах и обязанностях конечных пользователей. Однако, поскольку само программное обеспечение не изменяется, возможны более качественная поддержка, обучение и обслуживание, поскольку поддержка изначально разрабатывалась для данной версии программного обеспечения.
Process modeling, used to align product software and organizational structures, involves a major issue, when the conclusion is drawn that the product software and the organizational structure do not align well enough for the software to be implemented. In this case, two alternatives are possible: the customization of the software or the redesign of the organizational structure, thus the business processes. Customizing the software actually transforms the product software in tailor made software, as the idea of standardized software no longer applies. This may result in loss of support on the software and the need to acquire consultancy when issues arise in the usage of the software. Customizing however results in a situation where the organizational integrity is not adjusted, which puts less pressure on the end users, as less changes or shifts in workflows are required. This fact may positively add to the acceptance of any new (product) software application used and may thus decrease the implementation time and budget on the soft side of the implementation budget. Redesigning business processes is more sensible for causing resistance in the usage of product software, as altered business processes will alter tasks and responsibilities for the end users of the product software. However, while the product software is not altered, better support, training and service levels are possible because the support was created for the specific integrity of the software.
Руководящий принцип против профессии
Еще один вопрос при внедрении программного продукта – это выбор, а точнее, определение степени использования метода внедрения. Методы внедрения могут, с одной стороны, служить общим ориентиром, определяющим общую концепцию организации фазы внедрения в любом проекте. Такой подход предоставляет больше свободы для учета ситуационных факторов, не предусмотренных выбранным методом, но может приводить к неоднозначности при возникновении вопросов в ходе внедрения. С другой стороны, методы могут применяться как строгий профессиональный стандарт, когда использование метода рассматривается не как ориентир, а как профессиональная деятельность, требующая точного соблюдения. Этот подход особенно полезен, если процесс внедрения сложен и требует четких, выверенных действий. Организационное и управление качеством поддержат такой подход, поскольку строгое следование методу обеспечивает большую ясность на организационном уровне. Однако управление изменениями может указать на то, что большая гибкость в методе внедрения позволяет лучше учитывать человеческий фактор и особенности процессов внедрения.
Another issue on the implementation process of product software is the choice, or actually the question, to what extent an implementation method should be used. Implementation methods can on the one hand be used as a guiding principle, indicating that the method serves as a global idea about how the implementation phase of any project should run. This choice leaves more room for situational factors that are not taken into account in the chosen method, but will result in ambiguity when questions arise in the execution of the implementation process. On the other hand, methods can be used as a profession, meaning that the method should be taken strict and the usage of the method should be a profession, instead of a guiding principle. This view is very useful if the implementation process is very complex and is very dependent on exact and precise acting. Organizational and quality management will embrace this view, as a strict usage of any method results in more clarity on organizational level. Change management however might indicate that more flexibility in an implementation method leaves more room for the soft side of implementation processes.
Рамки осуществления
Помимо методов реализации, представляющих собой набор правил для внедрения конкретного продукта или услуги, рамки реализации служат структурированным подходом к управлению проектом, определяющим этап внедрения с точки зрения сроков, бюджета и качества. В качестве основы для реализации могут использоваться различные методы управления проектами. Поскольку данное описание посвящено внедрению программного продукта, наиболее подходящими методами управления проектами для поддержки этапа внедрения являются те, которые также ориентированы непосредственно на программное обеспечение и информационные системы. Практическое применение рамок для методов реализации иллюстрируется примерами использования метода разработки динамических и статических систем (DSDM) и Prince2 в качестве фреймворков управления проектами.
Apart from implementation methods serving as the set of rules to implement a specific product or service, implementation frameworks serve as the project managed structure to define the implementation phase in time, budget and quality. Several project management methods can serve as a basis to perform the implementation method. Since this entry focuses on the implementation of product software, the best project management methods suitable for supporting the implementation phase are project management methods that focus on software and information systems itself as well. The applicability of using a framework for implementation methods is clarified by the examples of using Dynamic and static systems development method (DSDM) and Prince2 as project management method frameworks.
ДСДМ
Сила метода разработки динамических систем заключается в том, что он использует принципы итераций и инкрементальной ценности, то есть проекты выполняются в повторяющихся фазах, каждая из которых добавляет ценность проекту. Таким образом, этапы реализации могут осуществляться инкрементно, повышая ценность важных аспектов проекта, таких как степень принятия, осведомленности и уровень квалификации на каждом этапе [F. Von Meyenfeldt, Basiskennis управление проектами, Academic Service 1999]. Помимо управления изменениями объема, инкременты также применимы в процессе моделирования при реализации фаз. Использование инкрементов позволяет согласовывать моделі процессов бизнес-архитектуры и программного обеспечения продукта, поскольку добавление большей детализации на каждом инкременте фазы сближает обе модели. DSDM также предусматривает поэтапное обучение, документирование и проверку.
The power of dynamic systems development method is that the method uses the principles of iteration and incremental value, meaning that projects are carried out in repeating phases where each phase adds value to the project. In this way implementation phases can be carried out incrementally and add value to important project aspects such as the degree of acceptance, awareness and skills within every increment [F. Von Meyenfeldt, Basiskennis project management, Academic Service 1999]. In addition to the management of chance scope, increments are also usable in the process modeling scope of implementation phases. Using increments can align process models of business architectures and product software as adding more detail in every increment of the phase draws both models closer. The DSDM also has room for phased training, documentation and reviewing.
Оценки
Использование встроенного метода дает возможность применять его для реализации программного продукта, с которым этот метод поставляется. Это подразумевает более простое использование метода и расширенные возможности поддержки. Очевидный недостаток встроенного метода заключается в том, что он может применяться только к конкретному программному обеспечению. Инженерам и консультантам, работающим с несколькими программными продуктами, может быть полезнее использовать универсальный метод, чтобы иметь единый подход к работе. Использование универсального метода, например, моделирования ERP, позволяет применять его к различным ERP-системам. В отличие от встроенных методов, использование универсальных методов позволяет инженерам и консультантам, работающим в компании, где в организациях клиентов внедрено несколько ERP-систем, адаптироваться к единому методу работы, вместо необходимости осваивать навыки для нескольких встроенных моделей. Однако универсальные методы имеют и недостаток: проекты внедрения могут стать слишком зависимыми от конкретной ситуации, что приведет к трудностям и усложнению процесса моделирования из-за меньшей доступности поддержки.
Using an embedded method brings the power that the method is designed to implement the software product that the method comes with. This suggests a less complicated usage of the method and more support possibilities. The negative aspect of an embedded method obviously is that it can only be used for specific product software. Engineers and consultants, operating with several software products, could have more use of a general method, to have just one way of working. Using a generic method like ERP modeling has the power that the method can be used for several ERP systems. Unlike embedded methods, the usage of generic methods enables engineers and consultants that operate in a company where several ERP systems are implemented in customer organizations, to adapt to one specific working method, instead of having to acquire skills for several embedded models. Generic methods have however the lack that implementation projects could become too situational, resulting in difficulties and complexity in the execution of the modeling process, as less support will be available.