CC BY
108
UDC 330.47=111 DOI: 10.5862/JE.216.13
I.I. Ilyin, A.I. Levina BUSINESS ARCHITECTURE MATURITY MANAGEMENT
И.В. Ильин, А.И. Лёвина УПРАВЛЕНИЕ ЗРЕЛОСТЬЮ БИЗНЕС-АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ
Today's fast-changing market environment makes certain demands on the management system of modern companies. The management system, represented by the enterprise architecture, should have a balanced structure and be mature enough to promptly react to inner and outer business challenges. The system approach to enterprise management means that enterprise architecture components must be formed, reformed and developed taking into account their interdependency. As processes and projects are core components of business architecture, not only they seriously influence, but also define its maturity level. There are a number of existing process and project management maturity models, but no well-known research concerning their joint maturity and the maturity of business architecture. The balance between maturity levels of the mentioned components as a key factor of the balanced business architecture and its development is in the focus of the paper. Analysis of the existing processes and project maturity models has shown that there is a high correlation between maturity levels of these management approaches. Combination of process and project management maturity levels is a reliable diagnostic tool for estimating whether the business architecture is balanced or not. At the same time combination of the maturity levels of process and project management in the company is a way to determine the path of sustainable development of the company's management system. The paper is focused on exploring the ways to manage business architecture maturity via its key components' maturity management.
ENTERPRISE ARCHITECTURE; BUSINESS ARCHITECTURE; BUSINESS PROCESS MANAGEMENT; PROJECT MANAGEMENT; MATURITY; CMMI.
Быстро меняющиеся условия современных рынков накладывают определенные требования на систему управления предприятием. Система управления, представленная архитектурой предприятия, должна иметь сбалансированную структуру и быть достаточно зрелой для того, чтобы оперативно реагировать на внутренние и внешние бизнес-вызовы. Системный подход к управлению предприятием предполагает, что элементы архитектуры предприятия должны формироваться, реформироваться и развиваться с учетом их взаимозависимости. Поскольку бизнес-процессы и проекты являются основополагающими элементами бизнес-архитектуры предприятия, они не просто сильно влияют, но и определяют уровень зрелости последней. Существует ряд моделей отдельно по процессной и проектной зрелости, но нет известных исследований, посвященных совместной зрелости процессов и проектов и зрелости бизнес-архитектуры. Предмет исследования — баланс между уровнями зрелости упомянутых элементов как ключевой фактор сбалансированной бизнес-архитектуры и ее развития. Анализ существующих моделей зрелости процессного и проектного управления показал, что уровни их зрелости тесно связаны. Сочетание уровней зрелости процессного и проектного управления — это надежный инструмент для определения сбалансированости бизнес-архитектуры. Кроме того, сочетание уровней зрелости процессов и проектов позволяет определить пути устойчивого развития системы управления компанией. В статье исследуются способы управления зрелостью бизнес-архитектуры предприятия через управление зрелостью ее элементов.
АРХИТЕКТУРА ПРЕДПРИЯТИЯ; БИЗНЕС-АРХИТЕКТУРА; УПРАВЛЕНИЕ ПРОЦЕССАМИ; УПРАВЛЕНИЕ ПРОЕКТАМИ; ЗРЕЛОСТЬ; CMMI.
Introduction. Enterprise architecture is one of the mainstream concepts in scientific management nowadays. The term «enterprise architecture» originates from IT and was initially used to define the structure of tools of IT system
development. While it is true that modern enterprises cannot do without IT-systems supporting their processes, the key factor of successful management lies not only in the sphere of IT.
To achieve and sustain the desired market position modern enterprises have to be rather flexible and dynamic in order to introdude the relevant changes as soon as there is need for them. The more complicated the enterprise is, the more difficult the process of introducing changes into its management structure is and the more components of this structure should be involved in. Now the «enterprise architecture» is treated as a broader concept and traditionally means a series of different components of the management system and relationship between them (different definitions can be found in [1],
[2], [3]).
Enterprise architecture in its current form has been developed as an answer to the problem of aligning business requirements and IT infrastructure (according to [4], [5]). So it is widely recognized that business process reengineering and transformation of IT infrastructure should be managed as a holistic, unified process. Thus, there are a lot of studies devoted to the analysis of alignment of business and IT architecture layers. In the meantime, it is crucially important to align the components within a single layer — it would form a backbone of the whole layer and provide reliable prerequisites for its development.
As business architecture is a foundation of the whole management system of a company, it seems vitally important to build a balanced business architecture and provide conditions for its further development. As any system is largely determined by the elements it consists of, the business architecture maturity level is determined by the maturity levels of its components. Nowadays there are some quite well-known approaches to estimating process and project management maturity but there is no complex research devoted to exploring their joint maturity or their contribution to the business architecture maturity. This paper is targeted on the analysis of the combination of the maturity levels of business architecture components — business process management and project management — as a key factor that forms a balanced business architecture and on determining the ways of its development. In other words, the paper is focused on the ways of business architecture maturity management via its components maturity management.
Business architecture and its components
Enterprise Architecture is an interconnected whole of principles, methods and models that are used in designing and building organizational structure, business processes, information systems and infrastructure. [4]
Enterprise architecture is a complex management tool, which is designed to provide effective enterprise management solutions in response to the challenges of the business environment. Heterogeneous structure of enterprise architecture requires continuous alignment of all its components which are grouped into so called architecture layers. In the meantime, the need to follow the realities of today's business causes the need to reform and develop enterprise architecture.
Traditionally, the components of enterprise architecture can be represented as a set of layers comprising of several structural components. The number and names of layers varies in different sources (for example, [4—6]), but the concept is more or less the same. For example, [5] focuses on the following layers:
- Corporate mission and vision, strategic goals and objectives;
- Business architecture: business processes, organizational and staff structure, workflow system;
- System Architecture (IT architecture): applications, data, hardware.
Most of the researchers agree that business process system is a key element of business architecture. A business process is «a special process that intends at the implementation of the basic objectives of the enterprise (business objectives) and describes the central sphere of its activity» [7]. Business processes as «a stable (regularly repeated), targeted set of interrelated activities, which according to a certain technology transforms inputs into outputs which have value to the consumer (client)» is the definition of the organizational structure of an enterprise given by [8]. The organizational structure is a stable set of interrelated and inter-subordinate organizational units to coordinate human resources of a company. «The process approach to management is a construction of a system of processes, control over these processes aimed at achieving the best results, improved efficiency and customer satisfaction» [8]. In
modern enterprises process management involves description, regulation, updating, and improvement of business processes system and the organizational structure in order to ensure the stability and reproducibility of the results.
In the meantime every company faces business challenges which cannot be met effectively in terms of business-as-usual approaches. Such challenges include both realization of external customer orders and introduction of innovative initiatives within the company. In such situations an enterprise has to establish some temporary structures to meet a new challenge or achieve a new business goal.
Some researchers confess in a more or less explicit form (for example, Architecture Development Methods of [6] and [5] the need to include means in the enterprise architecture for dealing with changes and transformations. In [9] it is underlined that the enterprise architecture among other elements should include «transitional processes for implementing new technologies in response to the changing needs of the business». As the enterprise architecture is a dynamic management tool, it requires a build-in mechanism for managing changes that is different from the routine operational processes. These reasons prove the need to add a project viewpoint to the business architecture model.
A project is traditionally defined as «a temporary organization that is created for the purpose of delivering one or more business products» [10]. Project management as an area of management dealing with the need to implement changes or realize unique activities. A large number of companies in various fields of activity are faced with the need to solve business problems that cannot be settled through standard routine business processes. It causes the need for development and implementation of project-based solutions aimed at achieving business goals, which states the necessity of introducing the project approach to the enterprise architecture.
If project management is considered as one of the subsystems of the enterprise management system, such an updated model of the business architecture provides: — a company with an effective tool for running projects;
— an integration between project management processes and processes of the whole company management;
— an effective mechanism to balance the interests of the operating and innovation activities of the enterprise, i. e. coordination of the interests of process and project management approaches based on consistent strategic guidelines.
The model of enterprise architecture enriched with the project management approach within a business layer is presented in Fig. 1. Structural elements of the enterprise architecture are connected and determine each other. The way the company performs in a business environment depends on its strategic goals and objectives. Some objectives are achieved by means of processes, others via projects. The system of company's business processes defines the organizational structure of the company, while project activity requires a temporary role structure. Potential conflicts concerning scarce resources distribution between these two types of activities can be resolved depending on how important a certain process or project is for achieving the strategic goals of the company. Such an interpretation of the business architecture allows differentiating process-based activities for running business as usual from project-based activities for facing unique business challenges. At the same time such a model sets processes and projects as key elements of the business architecture. Application of the enterprise model as a coherent whole of business and IT elements (see Fig. 1) is demonstrated, for example, in [11].
Maturity models of business process
management
There are a number of definitions of maturity and approaches to its estimating. The latter is beyond the scope of the current research. According to [12] «maturity levels characterize the overall state of an organization's processes» or according to [13] «a maturity level is a defined evolutionary plateau for organizational process improvement». Thus, the maturity concept always appears while talking about development of business: maturity is used to define the current state of a company or its elements and/or to evaluate the ways of a company's development. Before proceeding with enterprise architecture development it is necessary to find out the ways to define maturity levels of its components.
Fig. 1. Business processes and projects as components of the enterprise's architecture business layer
The majority of models of business process management maturity are based on the Capability Maturity Model (CMM) and its successor Capability Maturity Model Integration (CMMI) developed by the Software Engineering Institute at Carnegie Mellon University. CMMI introduced the concept of five maturity levels defined by cumulative requirements. A certain number of models have been developed by CMMI: Gartner's Process Maturity Model by [14], BPMM by [15], The Babson/Queensland University's Holistic BPM Maturity Model by [16], PEMM by [17].
According to [18] maturity levels are used to characterize organizational improvement relative to a set of process areas, and capability levels characterize organizational improvement relative to an individual process area (Fig. 2). As CMMI is a basement for a number of other well-known process maturity models, it has been chosen for further analysis.
Maturity Levels of CMMI Model are defined as follows:
• Maturity Level 1: Initial. At maturity level 1, processes are usually ad hoc and chaotic. The organization usually does not provide a stable
environment to support processes. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of tested and proven processes.
• Maturity Level 2: Managed. At maturity level 2, projects have ensured that processes are planned and executed in accordance with a policy; projects employ skilled people who have adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions.
• Maturity Level 3: Defined. At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods.
• Maturity Level 4: Quantitatively Managed. At maturity level 4, the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing projects. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. Quality and process performance is understood in statistical terms and is managed throughout the life of projects.
Organizations with an mature mastery of their processes. 5. Optimizing
л Organizations at this level routinely expact managers and employees to work together to \ improve processes. The/ understand their processes well enough that they can ) conduct systematic experiments to determine if changes will be useful oc not. —, / ^ Onlya few organizations have an organization wide_l\ 4. Managed у Continuous process improvement is enabled by quantitative feedback for the process and from piloting innwative new ideals and technologies.
understanding of how processes relate and have \ their corporate strategies and goals aligned, via the / management hierarchy to specific process activities. \ / 3. Defined / D etaiied m eas ures of the process and product quality are collected. Both the process and products are quantitatively understood and ccfitrolled.
Most organizations are between levers 2 and 3. They_l\ have processes documented and standardized but in \ many cases man ager's goals are cnfy 1 oosly linked to / process goafs. —i / 2. Repeatable/ The process for both management and engineering is documented, standardized and integrated by an organization methodology
/ 1. Initial / Basic project management processes are established to track cost, schedule] and functionality. The necessary discipline is in place to repeat earlier successes / As organ ization s I: ecome more mature they teg i n to ( conceptualize business processes and seek to organize \ them, repeat successes and measure results.
The process is ad hoc. Few activities are explicitly defined and success depends on individual effort and heroics. A- / Enterprenural organizations and new divisions \ that do things any way they can toget started. Organizations with an immature mastery of their processes.
Fig. 2. Five Maturity Levels of CMMI Model [19]
• Maturity Level 5: Optimizing. At maturity level 5, an organization continually improves its processes based on a quantitative understanding of its business objectives and performance needs. The organization uses a quantitative approach to understand a variation inherent in the process and the causes of process outcomes. Maturity level 5 focuses on continually improving process performance through incremental and innovative process and technological improvements.
Maturity model of project management
In terms of project management there are a number of maturity estimating approaches: P3M3 and PjM3 by AXELOS, OPM3 by Project Management Institute, PMMM or PMS-PMMM by PM Solutions and others. One of the most well-known project maturity models is P3M3 (which stands for Portfolio, Program and Project Management Maturity Model) and its
version for project management PjM3 originally developed by Office of Government Commerce, UK. According to [20], P3M3 uses a five-level maturity framework and the five Maturity Levels are: Level 1 — awareness of process, Level 2 — repeatable process, Level 3 — defined process, Level 4 — managed process, Level 5 — optimized process. This maturity model allows for independent assessment in any of the specific disciplines — portfolio management, program management or project management — so it can be treated as 3 different models. The maturity of each discipline must be assessed according to 7 process perspectives: Management Control, Benefits Management, Financial Management, Stakeholder Engagement, Risk Management, Organizational Governance, and Resource Management. Most organizations have strengths in some areas but not in others. P3M3 is designed to acknowledge these strengths as well as highlight weaknesses. [21]
^^t^eiersburgSate^olytechnicalUniversiíyJournaL^conomicsno' 2(216) 2015
For project maturity assessment the levels of the P3M3 have the following meaning:
• Level 1 — awareness of the process: Does the organization recognize projects and run them differently from its ongoing business? (Projects may be run informally without any standard process or tracking system.)
• Level 2 — repeatable process: Does the organization ensure that each project is run with its own processes and procedures to a minimum specified standard? (There may be limited consistency or coordination between projects.)
• Level 3 — defined process: Does the organization have its own centrally controlled project processes and can individual projects flex within these processes to suit a particular project?
• Level 4 — managed process: Does the organization obtain and retain specific measurements on its project management performance and run a quality management organization to better predict future performance?
• Level 5 — optimized process: Does the organization undertake continuous process improvement with proactive problem and technology management for projects in order to improve its ability to depict performance over time and optimize processes?
It is easy to notice that:
• project management maturity depends significantly on the quality of process management,
• project maturity levels are high-correlated with CMMI levels.
It seems reasonable to take CMMI as a maturity model for both process and project management for further analysis of their joint behavior.
Business architecture maturity
and its development
According to the model proposed in [22] projects together with processes form the backbone of the business architecture. They define the organizational structure, role structure and document flow of the enterprise. Thus, the maturity level of the business architecture depends largely on the maturity of its key components.
In such a situation there cannot and should not be a significant gap between levels of development of these two components. Process and project maturity model analysis allows creating a 2-dimensional matrix of process and
project maturity that helps to define the maturity of the whole business architecture (Fig. 3). Thus, process and project management are important components of the enterprise management system, the relationship between maturities of these components is a key factor of the business architecture development. They can be considered as indicators that determine the business architecture maturity level, i. e. the combination of their levels is a diagnostic tool that shows:
1) whether the business architecture is optimally balanced, acceptably balanced or not balanced enough;
2) which is the maturity level of the business architecture;
3) which is the next step of business architecture development (accumulating the level of the weaker component of the combination).
The business architecture can be considered as optimally balanced if processes and projects are managed at the same level (dark-grey cells on Fig. 3). It should be mentioned that optimally balanced architecture does not mean the highest maturity level, but the reasonable one for a particular company in the particular environment. Architecture balanced in a definite way at level 1 is different from that of level 5, but both situations mean that two core management approaches (process management and project management) are at the same level and can support each other's performance.
The business architecture can be called acceptably balanced in case of one-level difference between process and project management maturity levels (light-grey cells in Fig. 3). In such a case for further business architecture development it is reasonable to accumulate the capacity of the weaker component (in order to get into the dark-grey zone on Fig. 3).
The path of sustainable development of business architecture is depicted with arrows in Fig. 3. The development can follow any of the arrows shown in Fig. 3 or any can be composed of different pieces of these arrows. The important note is that the development path lies within the grey area of the matrix.
The difference of more than one level between process and project dimensions of the matrix means that an enterprise has an unbalanced business architecture maturity model which prevents it from further development. If an
Fig. 3. Process and Project Management Maturity Matrix
enterprise has a higher process maturity level and wants to keep on with process management implementation it will need to establish a process reengineering project. In its turn, it will require project management skills of a certain level in order to deliver a necessary result. Thus, the right way would be to raise the project capacity first which would provide more effective moving towards a new process maturity level. The reverse situation is a combination of higher project and lower process maturity levels. Project management is based on a certain system of processes and the more sophisticated the project approach adopted in the enterprise is, the more serious requirements for process management are.
Some combinations of maturity levels with a wide gap between them are not only undesirable but not even possible. For example, a company in reality cannot have level 1 of the process maturity and level 5 of the project maturity at the same time because it is impossible to reach such a high project management maturity without good enough process performance.
The analysis of each combination of the process and project maturity level within a business architecture is a subject of different research.
Results and Discussions. The competitiveness of a company depends on the maturity of its management system which is represented by the model of the enterprise architecture. A business architecture layer is a foundation that defines business performance of a company. Thus its maturity largely determines success and competitiveness of the business.
The paper focuses on understanding the role of maturity of business architecture core components — business process management and project management — and their contribution into the maturity level of business architecture. Analysis of correlation between maturity levels of business processes and projects delivered the following conclusions concerning enterprise architecture maturity:
— processes and projects are core components of the business architecture layer within the enterprise architecture;
— the maturity of the business architecture is defined by the joint maturity of its components, i. e. business architecture maturity management is represented via managing of process and project joint maturity;
— the combination of maturity levels of process and project management shows whether the business architecture is balanced or not: there
^^t^etersburg^tate^QiytechmcaJ^n^ 2(216) 2015
should not be a significant gap (more than one-level gap) between maturity levels of process and project management in order to provide the balanced business architecture;
— the relationship between business process management and project management maturity levels defines the path of sustainable development of the business architecture.
These items mentioned above are the elements of academic novelty of the research and are parts of the original methodology for analyzing enterprise architecture. The further steps of developing the methodology could be analysis of other architecture layers' maturity and defining the ways of complex enterprise architecture development.
REFERENCES
1. MIT Center for Information Systems Research. (January 25, 2014). CISR Research: Enterprise Architecture. Retrieved from Center for Information Systems Research. URL: http://cisr.mit.edu/research/ research-overview/ classic-topics/enterprise-architecture
2. Gartner I. IT Glossary: Enterprise Architecture. Retrieved from Garnter. URL: http://www.gartner. com/it-glossary/enterprise-architecture-ea (accused January 25, 2014).
3. Kondrat'ev V. Proektiruem arkhitekturu predpriiatiia. M.: Eksmo, 2007. (rus)
4. Lankhorst M. Enterprise Architecture at Work. Modelling, Communication, Analysis. Berlin, SpringerVerlag, 2013.
5. Kalianov G. Arkhitektura predpriiatiia i instrumenty ee modelirovaniia. Sait Vysshei shkoly upravleniia. URL: http://www.vshu.ru/files/ir01a.pdf (data obrashcheniia: 25.01.2014). (rus)
6. The Open Group. TOGAF Version 9. The Open Group Architecture Framework (TOGAF). London: TSO, 2009.
7. Bekker I., Vilkov L., Taratukhin V., Kugeler M., Rozemann M. Menedzhment protsessov. M.: Eksmo, 2010. (rus)
8. Repin V. Biznes-protsessy. Modelirovanie, vnedrenie, upravlenie. M.: Mann, Ivanov i Ferber, 2013. (rus)
9. CIO Council. Federal Enterprise Architecture Framework Version 1.1 September 1999. Retrieved from Institute for Enterprise Architecture Development: URL: http://www.enterprise-architecture.info/Images/ Documents/Federal%20EA%20Framework.pdf (accused January 25, 2014).
10. OGC. Managing Successful Projects with PRINCE2. London, TSO, 2009.
11. Ilin I.V., Lyovina A.I., Shirokova S.V., Hellmann N., Dubgorn A.S. ITIL and PRINCE2 in Practice. ucheb. posobie. SPb.: SPbGPU, 2014.
12. CMMI Product Team. CMMI® for Development, Version 1.3. Carnegie Mellon University, 2010.
13. Trinity Management Consultants Limited. Overview of Maturity Levels. Retrieved from Trinity Management Consultants Limited. URL: http://www. trinity-cmmi.co.uk/TR/Maturity-Levels.htm (accused February 01, 2014).
14. Scott D., Pultz J.E., Holub E., Bittman T.J., & McGuckin P. Introducing the Gartner IT Infrastructure and Operations. Gartner, 2007.
15. Object Management Group. Business Process Maturity Model (BPMM). Version 1.0. OMG, 2008.
16. De Bruin T., Rosemann M. Towards a Business Process Management Maturity Model. ECIS 2005 Proceedings of. Regensburg, Germany, 2005.
17. Hammer M. The Process Audit. Harward Business Review, 2007.
18. Software Engineering Institute. CMMI® For Development, Version 1.3. Carnegie Mellon University, 2010.
19. Chrissis M.B., Konrad M., Shrum S. CMMI: Guidelines for Process Integration and Product Development. Addison-Wesley, 2003.
20. AXELOS. Portfolio, Programme and Project Management (P3M3). Introduction and Guide to P3M3, 2013. Retrieved May 10, 2014, from P3M3 Official Site. URL: https://www.axelos.com/p3m3-ma turity-model.aspx
21. AXELOS. Portfolio, Programme and Project Management (P3M3). Introduction and Guide to P3M3. Retrieved from P3M3 Official Site. URL: http://www.p3m3-officialsite.com/P3M3Model/Model _mhtry.aspx (accused January 25, 2014).
22. Il'in I.V., Antipin A.R., Levina A.I. Modelirovanie biznes-arkhitektury protsessno- i proektno-orientirovannoi kompanii // Ekonomika i upravlenie. 2013. № 9(95). S. 32-38. (rus)
СПИСОК ЛИТЕРАТУРЫ
1. MIT Center for Information Systems Research. (January 25, 2014). CISR Research: Enterprise Architecture. Retrieved from Center for Information Systems Research. URL: http://cisr.mit.edu/research/ research-overview/classic-topics/enterprise-architecture
2. Gartner I. IT Glossary: Enterprise Architecture. Retrieved from Garnter. URL: http://www.gartner.com/it-glossary/enterprise-architecture-ea (accused January 25, 2014).
3. Кондратьев В. Проектируем архитектуру предприятия. М.: Эксмо, 2007.
4. Lankhorst M. Enterprise Architecture at Work. Modelling, Communication, Analysis. Berlin: Springer-Verlag, 2013.
5. Калянов Г. Архитектура предприятия и инструменты ее моделирования / Сайт Высшей школы управления. URL: http://www.vshu.ru/files/ir01a. pdf (дата обращения: 25.01.2014).
6. The Open Group. TOGAF Version 9. The Open Group Architecture Framework (TOGAF). London: TSO, 2009.
7. Беккер Й., Вилков Л., Таратухин В., Кугелер М., Роземанн М. Менеджмент процессов. М.: Эксмо, 2010.
8. Репин В. Бизнес-процессы. Моделирование, внедрение, управление. М.: Манн, Иванов и Фер-бер, 2013.
9. CIO Council. Federal Enterprise Architecture Framework Version 1.1 September 1999. Retrieved from Institute for Enterprise Architecture Development: URL: http://www.enterprise-architecture.info/Images/ Documents/Federal%20EA%20Framework.pdf (accused January 25, 2014).
10. OGC. Managing Successful Projects with PRINCE2. London: TSO, 2009.
11. Ilin I.V., Lyovina A.I., Shirokova S.V., Hellmann N., Dubgorn A.S. ITIL and PRINCE2 in Practice. учеб. пособие. СПб.: СПбГПУ, 2014.
12. CMMI Product Team. CMMI® for Development, Version 1.3. Carnegie Mellon University, 2010.
13. Trinity Management Consultants Limited. Overview of Maturity Levels. Retrieved from Trinity Management Consultants Limited. URL: http://www.trinity-
cmmi.co.uk/TR/Maturity-Levels.htm (accused February 01, 2014).
14. Scott D., Pultz J.E., Holub E., Bittman T.J., & McGuckin P. Introducing the Gartner IT Infrastructure and Operations. Gartner, 2007.
15. Object Management Group. Business Process Maturity Model (BPMM). Version 1.0. OMG, 200В.
16. De Bruin T., Rosemann M. Towards a Business Process Management Maturity Model. ECIS 2005 Proceedings of. Regensburg, Germany, 2005.
17. Hammer M. The Process Audit. Harward Business Review, 2007.
1В. Software Engineering Institute. CMMI® For Development, Version 1.3. Carnegie Mellon University, 2010.
19. Chrissis M.B., Konrad M., Shrum S. CMMI: Guidelines for Process Integration and Product Development. Addison-Wesley, 2003.
20. AXELOS. Portfolio, Programme and Project Management (P3M3). Introduction and Guide to P3M3, 2013. Retrieved May 10, 2014, from P3M3 Official Site. URL: https://www.axelos.com/p3m3-ma turity-model.aspx
21. AXELOS. Portfolio, Programme and Project Management (P3M3). Introduction and Guide to P3M3. Retrieved from P3M3 Official Site. URL: http://www.p3m3-officialsite.com/P3M3Model/Model _mhtry.aspx (accused January 25, 2014).
22. Ильин И.В., Антипин А.Р., Лёвина А.И. Моделирование бизнес-архитектуры процессно-и проектно-ориентированной компании // Экономика и управление. 2013. № 9(95). С. 32—38.
ILYIN Igor' I. — St. Petersburg State Polytechnic University.
195251. Politechnicheskaya str. 29. St. Petersburg. Russia. E-mail: ivi2475@gmail.com
ИЛЬИН Игорь Васильевич — заведующий кафедрой «Информационные системы в экономике и менеджменте» Санкт-Петербургского государственного политехнического университета, доктор экономических наук.
195251, ул. Политехническая, д. 29, Санкт-Петербург, Россия. E-mail: ivi2475@gmail.com
LEVINA Anastasiia I. — St. Petersburg State Polytechnic University.
195251. Politechnicheskaya str. 29. St. Petersburg. Russia. E-mail: alyovina@gmail.com
ЛЁВИНА Анастасия Ивановна — доцент Санкт-Петербургского государственного политехнического университета, кандидат экономических наук.
195251, ул. Политехническая, д. 29, Санкт-Петербург, Россия. E-mail: alyovina@gmail.com
© St. Petersburg State Polytechnical University, 2015
