Эталонная модель электронного правительства

Александр САМАРИНGlobal e-Government Forum 2014

7-8 October, 2014, Astana, Kazakhstanhttp://www.unpan.org/GeGF/2014

Эталонная модель электронного правительства v2 2

• Контекст• Эталонная модель электронного правительства• Проекции эталонной модели

Содержание

• Электронное Правительство (ЭП) – это использование современных информационных технологий для повышения эффективности и результативности государственного сектора

• Электронное правительство (electronic government) и электронное управление (electronic governance) рассматриваются совместно как единая система

• ЭП является социально-технической системой социально-технических систем (необходим совместный учет социальных и технических аспектов)

• Система – это функциональное целое, состоящее из взаимодействующих, взаимосвязанных или взаимозависимых частей

Основные определения

• Неограниченный жизненный цикл• Непредсказуемая и постепенная эволюция• Социально-технический характер• Коллегиальное принятие решений• Функционирование на уровне современного

предприятия • Способность к быстрому внедрению инноваций крайне

важна• Широкое разнообразие услуг • Высокий уровень безопасности персональных данных

Сложность ЭП как системы

• Цифровое побеждает физическое: все становится цифровым

• Быстрое побеждает медленное: обычная скорость исполнения - немедленно

• Группа побеждает одиночек: решение современных сложных проблем возможно только путем сотрудничества

• Большое побеждает малое: новые масштабы • Нет времени для ошибок и вмешательства человека в

рутинных операциях и интерфейсах

Цифровая эра (1)

• В дополнение к известным– дешевле, быстрее, лучше

• надо работать – более экологично, более гибко, более синергетически (т.е.

IoT), более всеобъемлюще, более безопасно • Смена фокуса при проектировании систем

– ОТ рассмотрения артефакта как отдельного объекта– К тому, как артефакт изменяется на

протяжении своего жизненного цикла – ОБРАЩАЯ ВНИМАНИЕ на то,

как артефакты изменяются совместно • Цель – обеспечение инноваций, которые

цифровом мире зависят от автоматизации процессов© A. Samarin 2014

Цифровая эра (2)

• Многие правительственные организации предоставляют аналогичные услуг, но по-разному

• Очень много общего между правительственными организациями

• Возможна существенная экономия при реализации ЭП © A. Samarin 2014

ПОЧЕМУ Эталонная модель ЭП (1)

Уровни власти

Архитектуры ЭП

Техническая архитектура

Архитектураданных

Архитектура приложений

Бизнес-архитектура

Муниципальный 100% 100% 100% 100%

Провинциальный 100% 100% 100% 80%

Федеральный 90% 100% 60-80% 70%

Национальный 90% 100% 70% 50%

• Существует способ, как объединить разнообразие и единообразие

• Проблема их сочетания известна в бизнесе, как "общие службы"

• Пример - Бизнес-подразделения (BU) имеют различные уровни компьютеризации и стандартное решение от ИТ подразделения никому не подходит

BU1 BU2 BU3

Общее решение

Уровень компьютеризации ИТ подразделение

Эталонная модель электронного правительства v2 10© A. Samarin 2014

BU1 BU2 BU3

Уровень компьютеризации

A CBB BAC

1) Стандартное решение использует процессы и службы

2) Все подразделения постепенно переходят к единой архитектуре

ИТ подразделение

• Становиться возможным избежать дублирования и необоснованных переделок

– готовые решения, инструменты, модели и архитектуры

– изменения происходят с комфортной скоростью

– становится центром трансформации общества

– наилучшие услуги для каждого гражданина

– плавно включаются инновации

– безопасность в дизайне

• Использование всей мощи корпоративной архитектуры (Enterprise Architecture - EA)– согласованные модели– платформенная архитектура– предприятие как система процессов – модернизация устарелых приложений

• Создание архитектурной группы в программе ЭП• Архитектурная группа является «зародышем» центра

компетенции ЭП

КАК работает эталонная модель ЭП

• Архитектор – это индивидуум, который переводит требования клиента в осуществимый план и направляет других при выполнении этого плана

• Корпоративная архитектура – это процесс перевода бизнес-стратегии в эффективное изменение предприятия путем создания принципов и моделей, которые описывают будущее состояние предприятия и обеспечивают его эволюцию

Корпоративная архитектура (1)

• В настоящее время, только корпоративная архитектура способна объединить разнообразие и единообразие

• Корпоративная архитектура осуществляет координацию между персоналом, процессами, проектами и продуктами в 4-мерном пространстве следующих осей:– Охват по размеру - подразделение, предприятие, отрасль,

правительство, вся страна, объединение стран, континент …– Охват по архитектурным областям – бизнес-архитектура,

ИТ-технологии, архитектура безопасности … – Охват по времени - жизненного цикла программного

решения, технологии, проекта, стратегии, предприятия …– Охват по секторам экономики – выявление общих и

специфических бизнес-практик© A. Samarin 2014

Корпоративная архитектура (2)

Проекты, решения, платформы …

Охват по времени

Охват по размеру против охвата по времени

Охват по размеру против охвата по архитектурным областям

Архитектурна группа в структуре программы ЭПРуководство программой

Программныйофис

Архитектурнаягруппа

Бюджет

Административная координация Техническая координация Финансовый контроль

Уровень вовлеченности

Внешняя команда

Внутренняя команда

Начальная фаза Проектная фаза Эволюционная фаза

• Ген. архитектор• Управление

– экспертный совет– контроль качества– финансы– библиотекарь

• Решения– архитекторы решений– аналитики

• Проекты– лидеры проектов

Основные роли с архитектурной группе

• Горизонтальные арх. – бизнес– приложения– информация– безопасность– инфраструктура

• Вертикальные арх.– здоровье– города– туризм– …

• Структура центра компетенции ЭП– Архитектурная группа– Группа социальных связей – Группа разработки– Группа эксплуатации– Группа преумножения знаний– Образовательные услуги– Обучение

Архитектурная группа является «зародышем» центра компетенции ЭП

Много заинтересованных лиц

• Граждане• Местный бизнес • Глобальный бизнес• Местные власти• Государственные агентства• Политические партии• Местные не правительственные орг. • Межд. не правительственные орг. • Производители ПО• Системные архитекторы • Руководители проектов

Матрица заинтересованных лиц и проекций ЭП

An example

• Взаимодействие между гражданином и правительственным учреждением

• Коммуникационное пространство гражданина• Стадии реализации ЭП• Межведомственный обмен данными и документами• Платформенная архитектура

– Подход– Практика– Управление проектами– Управление развитием платформы– Архитектурно-обоснованные закупки

Проекции ЭП (1)

• Предприятие как системы процессов• Использование процессов для усиления

информационной безопасности• Эталонная модель управления рисками• Процессная реализация архивного дела • Многоуровневая модель процессных решений • Практика процессных решений• Микро службы• Модернизация устарелых приложений • Перенос служб в «облака»

Проекции ЭП (2)

• Современные методологии и технологии являются потенциальной основой общественного прогресса

• Корпоративная архитектура обеспечивает совместное использование современных методологий и технологий

• Эталонная модель ЭП использует мощь корпоративной архитектуры для эффективного построения ЭП

• Эталонная модель ЭП – это основа для кооперации между странами при построении ЭП

• Эталонная модель ЭП применима для секторов как:– здравоохранение– «умный город» (smart-city)

Заключение

E-government reference model v2 28

• Вопросы?

• EKSALANSI website: http://www.eksalansi.org• Blog: http://improving-bpm-systems.blogspot.com• LinkedIn: http://www.linkedin.com/in/alexandersamarin• E-mail: alex@eksalansi.org • Twitter: @samarin • Mobile: +41 76 573 40 61• Book: www.samarin.biz/book

СПАСИБО

• Partner and governmental-entity interaction view• Partner view• Evolution of implementation view• The governmental entities integration view• Paperless or digital work view• Platform-based implementation view

– Platform-based approach– Platform-based implementation practices– Project management practices– Implementation governance view– Architecture-based procurement view

VIEWS (1)

Four communication patterns for exchanges between a partner and the

government

Government

2. Patrner-declaration

1. Government-announce

4. Partner-demand

Spread in time

3. Government-demand

Spread in time

Partners (citizen, business, and other organisations)

1. Government-announcement, e.g. broadcasting changes in a law2. Partner-declaration, e.g. communicating a change of the partner’s address3. Government-demand, e.g. inviting to pay taxes4. Partner-demand, e.g. requesting a certificate (fishing license)

A partner-initiated-demand may required several exchanges between the

partner and the government

Government

Time© A. Samarin 2014

1 2 3 4

The partner may need to deal with some ministries

Government

Ministry A Ministry B Ministry C

Methodologies:+ data modelling+ electronic document exchange

Tools:+ standard data schemas+ electronic signature

• data flow (black dashed lines)

Process

+ + + +

E-gov coordinates partner’s interactions with the government

Government

• control flow (black solid lines)

Ministry A Ministry B Ministry C

1 2 3 4

Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

Technologies:• standard data schemas• electronic signature+ BPM suite

Process --

E-gov unifies the communication between the partner and the ministries

GovernmentMinistry B

2a 2cx

Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

Technologies:• standard data schemas• electronic signature+ BPM suite

… …

Process

+ + + +

E-gov provides a social collaborative extranet for partners

GovernmentMinistry A Ministry B Ministry C

Methodologies:• data modelling• ED exchange• BPM discipline• process modelling+ ED management+ records management+ collaboration+ social

Technologies:• standard data schemas• electronic signature• BPM suite+ ECM

Social collaborative extranet

• Partner – governmental entity interaction view• Partner view• Evolution of implementation view• The governmental entities integration view• Platform-based implementation view

VIEWS (1)

Partner’s view

VIEWS (1)

Эталонная модель электронного правительства v2

Partners

Existing application

Coordination and integration backbone

e-Government

E-gov application architecture view

e-gov service

Government

Technologies:• BPM suite• SOA orientation• ECM

e-gov service

Partners

E-gov traditional application architecture

Portal

Government

Applicati

Partners

e-Government

E-gov introductory application architecture

e-gov service

Government

e-gov service

Partners

e-Government

E-gov transitional application architecture

e-gov service

Government

e-gov service

Coordination backbone

Service Service

Partners

e-Government

E-gov target application architecture

e-gov service

ServiceService Service

Partners

E-social system

E-social system application architecture

Public service

Private service

Professionalservice

Social service

Voluntary service

Steps of evolution in application architecture

Introductory architecture

Target architecture

E-Social system architecture

Portal-centric architecture

Transitional architecture

VIEWS (1)

Integration process instead of N-to-N connectivity

• Business (processing) envelope• Delivery (addressing) envelope• Transportation (routing) envelope

Use of many security envelopes

VIEWS (1)

Platform-based architecture (1)

• Business concern: How to deliver many similar applications for various highly-diverse clients; define everything up-front is not possible (typical BPM or ECM project)

• Logic– Developing individual applications will bring a lot of duplications– The provisioning of solutions should be carried out incrementally

with the pace of the target client– Consider a platform

1. must standardise and simplify core elements of future enterprise-wide system

2. for any elements outside the platform, new opportunities should be explored using agile principles

• Principles– The platform frees up resource to focus on new opportunities– Successful agile innovations are rapidly scaled up when

incorporated into the platform– An agile approach requires coordination at a system level– To minimise duplication of effort in solving the same problems,

there needs to be system-wide transparency of agile initiatives– Existing elements of the platform also need periodic challenge

Platform-based architecture (2)

A2A1 A3

Platform

S2 …S1

FunctionalityDelivery by solutions Delivery by applications

• There are two primary types of activity.– On-going and centralised platform evolution– Rapid implementation of solutions as mini-projects

• Platform evolution is carried out by an inter-organisational-units coordination committee

• The roles within mini-projects– A stakeholder – The team lead for administrative coordination– The product owner for functional coordination– The solution architect for technical coordination– The team member

Overall platform governance

Advantages of the corporate ECM platform

Dev env 1 Dev env 2

Development environment 3Generic web-

development platforms

DEVELOPMENT

Functionality

Basic features of a common ECM platform

Advanced features of a common ECM platform

Company-specific features

Process-centric integration

• Current development cost & time for a collaborative application– Cost: 40 – 200 K $– Time: 0,5 – 2 years

• Corporate platform program cost & time– Cost: 600 K $– Time: 1 year

• Expected development cost & time for a collaborative application within the corporate platform– Cost: 20 - 60 K $– Time: 1 - 3 months

Financial estimations

N apps.

Without common platform

With common platform

Solutions vs components

VIEWS (1)

• Entities are permitted to advance at different paces in their ascent to the top of the “ladder”.

Ladder of maturity meta-pattern

• The platform is designed to be tools-independent by standardizing data, information, interfaces and coordination between various capabilities.

Component-oriented design

VIEWS (1)

• It combines decomposition with agile implementation of “architected” components

Architecture-based agile project management

VIEWS (1)

Structural dependencies between various artefacts

Business initiatives (business-specific demand)

Business capabilities(business-generic demand)

IT capabilities (IT-generic supply)

Roadmap programmes(from AS-IS to TO-BE)

Business demand IT supply

Business strategicobjectives

Governance

Maturity improvement Requested maturity Business priority

IT tools(IT-specific supply)

Programme priority

Dynamic relationships between various artefacts

Manage business by processes

Manage processes BPM suite

• Implications– A formal way to discover points of the most leverage – The decision-making process is explicit and transparent– A strategy adjustment and validation becomes a routine on-going

activity during its implementation (like functioning of the GPS navigator)

Implications and example

VIEWS (1)

• Separation of duties• Architecture group: selection of IT • Procurement group: acquisition of such IT components

(licensees, installation, training, documentation, operations, etc.)

• Of course, the architecture group must make the selection logic as explicit as possible.

Architecture-based procurement

• Enterprise as a system of processes• Enhancing information security by the use of processes• Enterprise Risk Management reference model• Records management as an BPM application• Multi-layered implementation model• Agile solution delivery practices• Microservices• Various technologies around the implementation model• Modernisation of applications to become process-centric• Moving services to clouds

VIEWS (2)

• In the context of enterprise functioning, business activities must be coordinated

• Coordination maybe strong (e.g. as in the army) or weak (e.g. as in an amateurs football team)

• Coordination maybe implicit or explicit • Coordination maybe declarative (laws) and imperative

(orders)• Based on coordination, let us think about “levels of

cohesion” 1. process patterns (coordination within processes)2. processes3. cluster of processes (coordination between processes)4. system of processes (coordination between clusters of processes)

Enterprise as a system of processes

• Business case: typical “claim processing” process – claim, repair, control, invoicing, and assurance to pay

Process fragments – patterns

Click for animation

SI animated diagram

Click for animation

• Simple event-based (which looks like a state machine)

Coordination between processes (1)

Coordination between processes (2)

1. state-machine2. synchronous invocation3. asynchronous invocation4. fire and forget5. parallel processes6. co-processes (pattern SI)

• CLOPs are usually formed with functional processes which are implemented a particular business function, e.g. Field Services

• And a “halo” of extra processes1. monitoring 2. operating 3. governance

CLuster Of Processes (CLOP)

Enabler group, supporting group and customer group of clusters

Implicit coordination between CLOPs (1)

• Business Object (BO) lify-cycle as a process

Make coordination between CLOPs explicit (1)

• Add enterprise-wide event dispatcher

Functional view at a system of processes (1)

VIEWS (2)

Dynamic provision of the access

Extra relationships between activities

Mandatory: different actors because of the separation of duties

Potentially: different actors because of performance impact – avoid assigning mechanical (low-qualified “red”) activities and added-value (“green”) activities to the same actors

• There are security-related relationships between activities• Example

– “Activitiy_B” relates to Activity_A as “Validating the work”– These activities may be in different processes– No actors must be assigned to both “Role_1” and “Role_2”

Extra relationships between activities (3)

Activity_A

Activity_B

Carry out the work

Carry out the work Validating the work

Role_1

Role_2

• Doing the work– To which ROLES the work can be delegated– To which ROLES the work can be send for review

• Assuring the work– other ACTIVITIES to audit (1st, 2nd and 3rd party auditing)– other ACTIVITIES to evaluate the risk (before the work is started)– other ACTIVITIES to evaluate the risk (after the work is

completed)• Validating the work

– Other ACTIVITIES to check the output (errors and fraud prevention)

• Some ACTIVITIES must be carried out by the same actor, some ACTIVITIES must not

BPM and information security: Extra relationships between activities

VIEWS (2)

• Normal activities are enriched by “check-points”

Embed risk management into functional processes

ERM reference model

• Common functional capabilities• Enterprise as a system of processes• Enhancing information security by the use of processes• Enterprise Risk Management reference model• Records management as an BPM application• Multi-layered implementation model• Agile solution delivery practices• Microservices• Various technologies around the implementation model• Modernisation of applications to become process-centric• Moving services to clouds

VIEWS (2)

• Symptoms of becoming legacy– ad-hoc integration– difficult incorporation of new technologies– old programming techniques– expensive maintenance– heavy releases and upgrades– availability of industrial products for previously unique

functionality (e.g. event management)– some functionality is a commodity right now (e.g. BPM and BRM)– just slow to evolve

• What is the root cause?– Emergent/historical grow and not architected evolution

Typical problems with legacy software

• Implement end-to-end processes with the maximum reuse of existing IT applications and infrastructure

• Agile (with the pace of business) provisioning of business solutions

• From disparate IT applications to a coherent business execution platform which will “liberate” people for business innovations

• Business evolution to drive technical transformation• BUT Application as a unit of deployment is too big

The goal of modernisation

• Step-by-step technical transformation by:1. Disassemble into services2. Add, if necessary, more services3. Assemble via processes

• Combine various tactics: assemble, rent, buy, build, outsource, standardised, re-engineered

• Incremental improvements and refactoring within a well-defined big picture

• Intermix business evolution and technical transformation• Keep the users happy and feel secure

How to carry out the modernisation

Monolithic applications are decomposed into interconnected services

Monolith application

GUI screen 2GUI screen 1 GUI screen 3

Business logic

BO1 persistence BO2 persistence

Business logic service

Interactive service 1

Coordination

BO1persistence service

BO2persistence service

Assembled solution

GUI screen 2GUI screen 1 GUI screen 3

Business logic

BO1 persistence BO2 persistence

• Only the flow of data is traceable

• Flow of control is explicit, becausethe primary importance is the result of working together, but not individual exchanges(think about football)

How to coordinate?

• By processes• By events (EPN)• By rules, work-load, etc.

Several coordination techniques may be used together

Transformation from typical inter-application data flows to end-to-end

coordination of services

• To externalise the flow of control from existing monolith applications

Using events

• The danger of “DOUble Master” (DOUM) anti-pattern – particular data (actually a business object) are modified via application or process but not either

• Few techniques– lock-down the data manipulation interface in the application (a

screen) and provide a similar functionality in the process– dynamic provisioning of the access to a screen for a staff member

who is carrying out a related activity (see next slide)– decomposition of a screen into separate functions, e.g. Create

(out-of-process), Update (within-process) and Delete (separate-process)

– combination of previous ones

Co-existence of a legacy application and a process solution

• Business processes make bigger services from smaller services

• The relationship between services and processes is “recursive” – All processes are services– Some operations of a service can

be implemented as a process– A process includes services

in its implementation

Process-centric solutionsAssemble via processes (1)

• Who (roles) is doing What (business objects), When (coordination of activities), Why (business rules), How (business activities) and with Which Results (performance indicators)

• Make these relationships explicit and executable

What you model is what you execute

“The map is the app”

Process-centric solutionsAssemble via processes (2)

Process-centric solutionsMulti-layer implementation model (1)

A - SharePoint

B – in-house development

C – SAP ECC6

SAP BW/BI, etc.

NetWeaver PI, SolMan, etc.

NetWeaver BPM, etc.NetWeaver BRM, Java, ECC6, etc.

XSD, Java, .Net

SQL Server, Oracle, etc.

Multi-layer implementation model and other technologies

• Healthcare

RESULTS

Enrich Knowledge

Improve Operations

acquisition channels for external data/information/ knowledge

disseminationchannels of internal data/information/ knowledge

Methods, practices, laws, international regulations, etc.

Knowledge for Healthcare

Processes & Services

… … …

DiagnosticPreliminary analysis Treatment Recovery

PartnerPartnerPartnerPartnerPartners

Coordination

Healthcare reference model (1)

Healthcare Platform

acquisition channels dissemination

channels

Specialised Apps.

Web access

Mobile access

PatientCRM

Web acces

Mobile access

DoctorCRM

Access

Enrichment

RBACKnowledge Mgmt. Procedures

BPMECM

StorageECM

CoordinationBPMsBI

PartnerPartnerPartnerPartnerPartners

Healthcare reference model (2)

Healthcare reference model (3)Modern Healthcare System (MHS)

Hospitals Clinics

Virtual Doctor’s Offices

Insurance Social

PatientsMHS WEB & Cloud

• All smart-cites deliver the same services, albeit in a different manner

• Realisation of smart-city potentials would benefit from a holistic approach

• BSI standard PAS 181:2014

ANNEX Smart-city implementation reference model

• Let us use the power of modern technologies to enable and drive societal transformation

Conclusion

E-government reference model v2 114

• QUESTIONS?

• EKSALANSI website: http://www.eksalansi.org• Blog: http://improving-bpm-systems.blogspot.com• LinkedIn: http://www.linkedin.com/in/alexandersamarin• E-mail: alex@eksalansi.org • Twitter: @samarin • Mobile: +41 76 573 40 61• Book: www.samarin.biz/book

Thanks

Эталонная модель электронного правительства

Technology

Transcript of Эталонная модель электронного правительства

Построение эффективной системы электронного маркетинга

Построение эффективной системы электронного маркетинга. EMW 2012

KazExportGarant › files › md7fyz9xz0g04o8o08k… · Web viewКазЭкспортГарант создан Постановлением Правительства Республики

ПСИХОЛОГіЧНА МОДЕЛЬ РАНЬОГО …rvua.com.ua/media/144/a5432393cd1a9048a4e64e3abbdd939d.pdfПСИХОЛОГіЧНА МОДЕЛЬ РАНЬОГО ВТРУЧАННЯ:

Автоматизация работы мобильных сотрудников с помощью электронного портфеля Workestr

USB Модель DMC-XS1 DMC-FS50

Semantic web и продукционная модель знаний

Караиванов Георгий - Drupal в проектах Электронного правительства

Переносной Верстак Модель 460-12

финансовая модель стартапа 3

Опыт внедрения системы электронного документооборота

Брендинговое агентство REALPRO для Правительства Республики Горный Алтай

Divaan - модель Elvis

Постановление Правительства РФ отdtm.drive.igora.ru/files/rules_ru.pdfПостановление Правительства РФ от 16.12.2013 n 1156

Союз-PLM – прикладная платформа для автоматизированных ... · • Автоматизация электронного согласования

Платформа для эффективных продаж электронного контента

БИНАР DREAMTOWARDS ЭТО БИЗНЕС МОДЕЛЬ, С … · БИНАР dreamtowards ЭТО БИЗНЕС МОДЕЛЬ, ... завоевав к себе доверие как

УТоЧНеННаЯ МаТеМаТИЧеСКаЯ МодеЛь КоаГУЛЯЦИИ …

ГОСТ 26351-84 Модель влажности воздуха над территорией … · Title: ГОСТ 26351-84 Модель влажности воздуха над

Модель: HYW-20 T5HYW-20 T5