Äriprotsesside modelleerimine ja automatiseerimine Loeng 8 Äriprotsesside modelleerimise metoodika ja dokumenteerimine

Äriprotsesside modelleerimine ja automatiseerimine Loeng 8 Äriprotsesside modelleerimise metoodika ja dokumenteerimine Enn Õunapuu enn.ounapuu@ttu.ee

Feedback & Control Ronald E. Giachetti October 20, 2014

Põhilised tegevused äriprotsesside arendamiseks 1. Valdkonna mudel 2. Arendatava protsessi valik 3. Probleemid arendatavas protsessis ja arenduse eesmärkide paika panemine 4. Protsessi as-is kirjeldus 5. Protsessi kaevandamine ja arenduse ideede genereerimine 6. Protsessi to-be kirjeldus 7. Protsessi parenduse mõõtmine

Põhilised tegevused äriprotsesside arendamiseks 1. Valdkonna mudel

The Triptych Dogma The dogma says : Before software can be designed one must understand the requirements Before requirements can be prescribed one must understand the domain

Definition 1 Domain By a domain, or, more precisely an application domain, we shall understand (i) a suitably delineated area of a human activity, that is (ii) a universe of discourse, something for which we have what we will call a domain-specific terminology (iii) such that this domain has reasonably clear interfaces to other such domains

Definition 2 Domain Description By a domain description we shall understand (i) a set of pairs of informal, for ex., English language, and formal, say mathematical, texts (ii) which are commensurate, that is, in English text reads the formulas, and (iii) which describe the simple entities, operations, events and behaviours of domain in a reasonably comprehensive manner

Mida tuleks esitada, et määratleda valdkonna mudel? Mõisted ja selgitused Mõistete vahelised seosed Osapooled ja nende huvid Ärimudel

Põhilised tegevused äriprotsesside arendamiseks 1. Valdkonna mudel 2. Arendatava protsessi valik

Definition A synthesis of literature shows that there are mainly 9 building blocks to help us describe a business model: The value proposition of what is offered to the market; The target customer segments addressed by the value proposition; The communication and distribution channels to reach customers and offer the value proposition; The relationships established with customers; The core capacities needed to make the business model possible; The configuration of activities to implement the business model; The partners and their motivations of coming together to make a business model happen; The revenue streams generated by the business model constituting the revenue model; The cost structure resulting of the business model.

E-gov model Why we need?

Extensive duplication, overlap and gaps in critical Government functions* 50 agencies implement Federal drug control strategies 29 agencies administer 541 clean air, water, and waste programs 23 agencies administer 200 programs that provide assistance to countries formerly part of the Soviet Union 13 agencies administer 342 Federal economic development-related programs 12 agencies administer more than 35 food safety laws Page 17 10/20/2014 17 * Urgent Business for America: Revitalizing the Federal Government for the 21 st Century. The Report of the National Commission on the Public Service, January 2003.

Extensive duplication, overlap and gaps in critical Government functions (continued) 11 agencies administer 90 early childhood programs 9 agencies administer 86 teacher training programs 9 agencies administer 27 teen pregnancy programs 8 agencies administer 50 different programs to aid the homeless 7 agencies administer 40 different job training programs 10/20/2014 18

This is not a technical problem! (or is it?) Systems are specified without an enterprise-level understanding of the: How they support the Mission Objectives Business processes (e.g., supply chain) Existing technical architecture New technology initiatives In the Federal Government, there is no good way today to gain cross-agency, cross-organization insight. and the supply chain today goes BEYOND the Federal Government Post-911 coordination between Office of Homeland Security, other Federal agencies, State, and Local law enforcement, Fire departments, etc. 10/20/2014 19

Põhilised tegevused äriprotsesside arendamiseks 1. Valdkonna mudel 2. Arendatava protsessi valik 3. Probleemid arendatavas protsessis ja arenduse eesmärkide paika panemine

Page 21 E-Government: Unification and simplification around citizen needs For individuals Easy to find, one-stop shops for citizens creating single points of easy entry to access high-quality governmental services For businesses Reduce the burden on businesses through the use of Internet protocols, simplifying interactions, and consolidating redundant reporting requirements For government agencies Make it easier for states and localities to meet reporting requirements, while enabling better performance measurement and results (e.g., grants) Internal efficiency and effectiveness Reduce costs for Federal Government administration by using best practices in areas such as supply chain management, financial management, and knowledge management 10/20/2014 21

The Vision: Order of magnitude improvement in the federal government s value to the citizen; with decisions in minutes or hours, not weeks or months 10/20/2014 22

How? Unify Infrastructure Unify access to data stores Collect the data once (requires agreement on data definitions) Integrate customer interface Monitor and measure (define success and measure) Simplify Processes Define and build integrated delivery channels The Teeth If you don t play, you don t get funded The FEA is a framework for making IT investment decisions for FY 2015 Budget (Form 300s) 10/20/2014 23

The Federal Enterprise Architecture (FEA) is: A Business-Focused Framework for Cross-Agency, Governmentwide Improvement A new way of describing, analyzing, and improving the Federal Government and its ability to serve the citizen The FEA will provide the ability, for the first time, to look across the Federal Government and identify opportunities to collaborate, consolidate, and leverage IT investments 10/20/2014 24

The FEA is a set of inter-related reference models to facilitate collaboration and information sharing Federal Enterprise Architecture (FEA) Business-Driven Approach Performance Reference Model (PRM) Government-wide Performance Measures & Outcomes Line of Business-Specific Performance Measures & Outcomes Business Reference Model (BRM) Lines of Business Agencies, Customers, Partners Service Component Reference Model (SRM) Service Layers, Service Types Components, Access and Delivery Channels Data Reference Model (DRM) Business-focused data standardization Cross-Agency Information exchanges Technical Reference Model (TRM) Service Component Interfaces, Interoperability Technologies, Standards Recommendations Component-Based Architecture 10/20/2014 25

The FEA Business Reference Model (BRM) is a framework for describing the Lines of Business performed by the Federal Government independent of the Agencies that perform them Citizen to Government Access Channels Government Employee to Employee Access Channels Telephone -Voice -Interactive Web Services Program Admin Public Asset Management Marketable Asset Management Defense & Nat l Security Ops Diplomacy & Foreign Relations Disaster Management Domestic Economy Education Energy Management Insurance Public Health Recreation & National Resources Social Services R&D & Science Telephone -Voice -Interactive E-system to System/ Web Services E-system to System Legislative Management Business Management of Information IT Management, Regulator Management Planning and Resource Allocation Public/ Private Partnerships Internet/ Portal Services for Citizens Services to Citizens Public/Private Partnerships Fax Kiosk Fax Support Delivery of Services Compliance Regulated Regulated Activity Activity Approval Approval Consumer Safety Safety Environmental Management Law Law Enforcement Legal Revenue Revenue Collection Collection Trade Trade (Import/Export) (Import/Export) Transportation Workforce Workforce Management Management Intranet/ Portal Face to Face Face to Face Mail Mail Controls and Oversight Public Affairs Internal Risk Management and Mitigation Federal Financial Assistance Inter-Agency Internal Operations / Infrastructure Human Resources, Financial Management Admin Supply Chain Management Human Resources, Financial Management Admin Supply Chain Management 10/20/2014 26

Nüüd läheme teise poole juurde -IT Milline peaks meie süsteem olema? Kergesti muudetav Väheste vigadega Kasutatav

Kuidas ajalooliselt on asjad kulgenud? Esiteks olid rakendused ja andmed ühtsed. Teises etapis eristati andmed rakendustest. Tekkisid ühtsed andmebaasisüsteemid. Andmete normaliseerimine. Kolmandaks eraldati iga tegevus eraldi teenuseks ja toodi välja protsessimudelid. BPMN ja süsteemid Edasi toodi otsustused välja protsessimudelitest ja kasutati reeglisüsteeme.

Process mining: Linking events to models world business processes people machines components organizations models analyzes supports/ controls specifies configures implements analyzes software system records events, e.g., messages, transactions, etc. process/ system model discovery conformance event logs

Mida protsessi disain sisaldab? Roll /Role/ ehk kes osaleb? Tegevus /Activity/ ehk mida tehakse? Tellimuse sisestamine Otsustuskoht /Decision/ ehk millised on valikud? Automaadi vastus? Rakendus, andmebaas /Application or Data WVine base/ süsteem kus tegevusi tehakse Olek /Status/ - tähistab olukorda/seisundit, mis käivitab ja lõpetab protsessi Visiit planeeritud

Äriprotsessi konteksti perspektiiv

Dokumendi struktuur Äriline taust (kasutusloo vajadus) Osapooled, info liikumise suund ja järjekord Protsessi põhivoog koos sõnumite sisuga Veasituatsioonid ja veateated Mõõdikud

Küsimused?