Кой се нуждае от Enterprise Architecture и защо?

Copyright © 2009 Забегалин Е.В.

1 Текущо състояние на архитектурните методологии и практики

AT чужди държавиах, отдавна е разработен методически и практически определен набор от теми, чийто предмет е архитектурата на сложниорганизационно-технически обекти като предприятия, „електронни правителства“, корпоративни информационни системи.

AT Русия, въпреки факта, че термините "архитектура на информационната система"„ИТ архитектурата на предприятието“, „архитектурата на електронното правителство“ отдавна са станали модерни и се използват широко сред ИТ специалистите, сериозен методологичен интерес към „архитектурните“ теми има само в тесен кръг от ентусиазирани специалисти (включително автори на публикации), дейности, които в тази област имат предимно образователен и популяризиращ характер.

Следователно, ако говорим за стандартизацията на „архитектурните“ методологии в Русия и последващото им широко практическо използване в местни компании, тогава това изглежда е въпрос на несигурно бъдеще. Въпреки това, „архитектурното“ движение в руските предприятия трябва да започне на практика сега.

„Архитектура на предприятието“, на руски „Архитектура на предприятието“ (AP), се е развила в обща дисциплина като стъпка историческо развитиенабор от методологии, свързани с архитектурата на автоматизираните информационни системи – това са методологиите на J. Zachman, чл. Спивак, ЦИМОСА, ГЕРАМ, ТОГАФ и др. Анализът на този исторически процес е представен достатъчно подробно в.

Към днешна дата най-известните и значими източници на съвременни методологични идеи и практики на ЕА включват:

Рамката на Zachman за корпоративна архитектура;

ISO 19439:2006 „Интеграция на предприятието – Рамка за моделиране на предприятието”;

Стандарт ISO 15704:2000. Индустриални системи за автоматизация - Изисквания за корпоративни референтни архитектури и методологии;

"Federal Enterprise Architecture" (FEA), практикувана и развивана от правителството на САЩ;

„Разширена корпоративна архитектурна рамка“ (E2AF), разработена от независима организация"Институт за развитие на корпоративната архитектура";

Рамката за отворена групова архитектура (TOGAF).

Заедно с това в Русия през 2000 г. е разработена и публикувана концептуалната архитектурна схема "3D-Enterprise", в която матричните идеи на J. Zachman са допълнени с трето - временно - измерение, което да отразява трансформацията на структурата на предприятието.

Отбелязва се, че значителният интерес към темата за АП се обяснява с спешната нужда на съвременните мениджъри и анализатори от многомерно системно описание и планиране на процеса на развитие на организации (включително предприятия). Интересът към подобно описание е продиктуван най-малкото от практическата необходимост винаги да има достатъчно смислени знания за текущата структура на организацията, които могат да се използват и за рационално планиране на трансформацията на организацията в променящи се условия. Ако такова знание е налично, поддържано и използвано в организацията в отчуждена форма, тогава то се превръща в ефективен инструмент за управление. Това важи особено за новите лидери и мениджъри на организации (предприятия).

Фигура 1 - Мениджърите и анализаторите имат практическа нужда винаги да имат достатъчно смислени познания за структурата на организацията (предприятието)

В същото време нивото на абстракция и сложност на повечето от изброените методологии остава много високо и може да попречи на ефективното им използване в техните организации. практически мениджърии специалисти. различен вид„Матриците“ и „кубовете“, предложени в изброените методологии, може да изглеждат ненужно изкуствени и следователно неудобни за практическа употреба. Така например природата на същата „матрица на Захман“ изглежда по-скоро философска, отколкото практическа инженерна, тя е по-скоро схематично визуализирана спецификация на систематичен подход към анализа на големи и сложно структурирани организационни и технически обекти. Това обаче ни най-малко не отменя огромната методологическа стойност и практическото значение на развиващата се дисциплина АП.

В интерес на практическото приложение на дисциплината EA, преодоляването на тази изкуственост може да започне с търсене на отговор на въпроса: кой и защо в едно предприятие може да се нуждае от „Enterprise Architecture“?

2 Цел на "Enterprise Architecture"

Фигура 2 изобразява схематично структурата и съдържанието на обобщеното предприятие. От тази диаграма може да се види, че AP, разглеждан и използван като модел, може да бъде практически търсен в предприятието само като инструмент за управление, тъй като нито техническият, нито производственият персонал се нуждаят от AP, за да изпълняват производствените си функции.

Това заключение следва от факта, че всички обекти на управление, посочени в диаграмата, са едновременно обекти, които трябва да бъдат отразени в модела на EA, който в бъдеще също ще стане обект на управление (архитектурният модел на предприятието е показан на диаграмата като неговия компонент).

Фигура 2 - Обобщена структура на предприятието

Като инструмент за управление, EA може да се използва за подпомагане на всички негови основни функции - анализ, планиране, организация, мотивация, контрол, координация.

Фигура 3 - "Enterprise Architecture" може да се използва за поддръжка на основни функции за управление

От ролята на EA като инструмент за управление могат да бъдат извлечени поне две основни функции на корпоративната архитектура:

в контура на оперативното управление на предприятието - това е формализиране и предоставяне на отчуждени знания за съществуващата структура и функциониране на предприятието;

в контур стратегическо управлениепредприятие - е формализирането и осигуряването

отчуждени знания за планираните структурни и функционални трансформации на предприятието.

Фигура 4 - Основните функции на "Enterprise Architecture"

AP може да се използва с тези функции на всички нива на управление: от ниво на управление на предприятието до цех. Това (изрично или косвено) се осигурява от добре познати методологии -

"Zachman Framework за Enterprise Architecture", "Extended Enterprise Architecture Framework", "TOGAF",

"GERAM", стандарт ISO 19439-2006 ("Общи", "Частични", "Специални" нива).

След J. Zachman, най-специфичните и последователни нива на управление за използването на AP са предложени в схемата “3D-Enterprise” - “Основни нужди, цели, планове, ограничения”, “Бизнес модел”, “Логически модел”, “ Техническа архитектура”, „Детайлно изпълнение”, „Практика на използване”.

3 Състав на "Enterprise Architecture"

Всички архитектурни методологии са съгласни, че за достатъчно смислено описание на устройството на предприятие (организация) е необходимо да се използват много различни гледни точки (изгледи) на това устройство. Тези гледни точки могат също да бъдат посочени като архитектурни домейни, аспекти на съдържанието и други подобни. Описването (и моделирането) на структурата на едно предприятие от много различни гледни точки води до „Архитектура на предприятието“.

Различните методологии използват различни набори от архитектурни гледни точки. Например:

в Zachman Framework за Enterprise Architecture това са „Данни“, „Функция“, „Мрежа“, „Хора“, „Време“, „Мотивация“;

в Extended Enterprise Architecture Framework (E2AF) е „Бизнес“, „Информация“, „Информация

Системи“, „Технологична инфраструктура“;

в GERAM и в ISO 19439-2006 това са "Функция", "Информация", "Ресурс", "Организация";

в TOGAF те са "Бизнес", "Информация", "Приложение", "Технология".

Авторът на тази статия счита за практически целесъобразно да се преодолее такова разнообразие от методологични подходи към избора на съществени аспекти на ЕА чрез използването на всеки един прост и разбираем принцип за логическото извеждане на тези аспекти.

Такъв принцип може да следва от общото фундаментално разбиране за "системата" като набор от целенасочено взаимодействащи си елементи. Въз основа на това могат фундаментално да се разграничат следните основни и лесно разбираеми съществени аспекти на "Enterprise Architecture":

1) Строителен аспект- предприятието е изградено от много различни физически и информационни компоненти, включително: дълготрайни активи и друга собственост, консумирана и произведена енергия, персонал, хартиени документи, електронна информация, средства за автоматизация и автоматичен контрол, тоест това са „градивните тухли“ от които физически се състои предприятието. Към този аспект можете да приложите и синонимния термин - структурен аспект.

2) Функционален аспект- предприятието функционира, произвежда продукти, предоставя услуги, закупува и продава суровини, материали, продукти, в него се извършват технологични и бизнес процеси, тоест този аспект подчертава външното и вътрешното проявление на дейността на предприятието;

3) Логически аспект- дейността на предприятието е целенасочена, в съответствие с целите на предприятието се определят неговата конструкция и функционални структури. Този аспект подчертава бизнес смисъла на създаването и функционирането на предприятието.

Основните компоненти на логическата структура на предприятието са такива спекулативни компоненти като целта, мисията, визията, целите на предприятието, мястото му на пазара, принципите за избор на основните видове строителни компоненти, принципите на функциониране и развитие на предприятието.

AT В матрицата на Zachman този аспект е обозначен с името на първия ред „Обхват“ („Целта на ред 1 е да се определят границите на Предприятието, какво е включено…“).

AT Federal Enterprise Architecture (FEA) е „референтен модел на производителност“.

AT E2AF и в GERAM логическият аспект не е изрично разграничен и е включен в аспекта "Бизнес". Основните принципи на E2AF обаче гласят: „Няма стратегия, няма корпоративна архитектура... Без обхват – няма корпоративна архитектура

Обхватът и целите и задачите определят нивото на абстракция на архитектурата на предприятието ... Бизнес двигателите, целите и задачите са водещи ..." .

AT Логическият аспект на TOGAF съответства на „Архитектурна визия“ („... ключови елементи на „Архитектурна визия“- ...

мисия, визия, стратегия и цели на предприятието ..., включват принципи на архитектурата, определят обхвата на покритие на предприятието, специфичните домейни на архитектурата ..." ).

Обобщавайки прегледа на логическия аспект и използвайки философския език, може да се твърди, че логическият аспект на структурата на предприятието е необходим, за да представи „Интегралната идея на предприятието“, „Интегралната идея на предприятието“ , "Интегрална концепция на предприятието", на английски можем да предложим - "The Notion of the Enterprise" .

4) Хронологичен аспект- фирмата се създава, работи и се променя във времето. Миналите, настоящите и планираните структурни състояния на предприятието трябва да бъдат записани, т.е. - това е "История на живота".

В GERAM, в ISO 15704-2000, ISO 19439-2006, са предложени много етапи от жизнения цикъл за структуриране на времевия аспект: "Идентификация", "Концепция", "Изисквания", "Проектиране", "Внедряване", "Експлоатация", „Извеждане от експлоатация“.

AT методология TOGAF - Метод за развитие на архитектурата (ADM) - времевият аспект се отразява от последователността от етапи на развитие, внедряване и промяна на самата "Архитектура на предприятието".

Схемата "3D-Enterprise" позволява планиране на бъдещите състояния на предприятие във времевото измерение на EA, включително индивидуални проекти и програми за развитие. По-специално, последователността на внедряване на технологични компоненти (системи) на предприятието може да включва: стратегически анализ на целите и нуждите, проектиране на технически решения, подробно внедряване на система от решения, внедряване на решения, използване (работа) на системата , подобряване на системата.

Фигура 5 - Основни гледни точки върху структурата на предприятието

По този начин „Архитектурата на предприятието“ може да се дефинира като структурата на предприятието, разглеждана от неговото ръководство най-малко от четири основни гледни точки (в четири основни аспекта) и представена (включително моделирана) от подходящ набор от четири основни типове архитектури Предприятия: логическа, конструктивна (структурна), функционална и хронологична.

Компонентите на архитектурата на сградата на предприятието могат да бъдат разгледани:

организационна архитектура е организационната структура на предприятието;

архитектурата на собствеността е структурата на собствеността на предприятието;

информационната архитектура е структурата на набор от документи (организационни, регулаторни, технически и др.) и корпоративни информационни бази данни;

Производствено-технологичната архитектура е структурата на производствените и енергийните мощности на предприятието, както и структурата на комплексите за измерване и автоматизация и комплексите от оборудване за автоматизация.

Да се Компонентите на функционалната архитектура на предприятието могат да бъдат приписани на:

структура на функционалните системи и подсистеми на предприятието;

структура на бизнес функциите и бизнес процесите на предприятието;

структури на потоците от материали и информация в предприятието.

Фигура 6 - Интегриран изглед на "Enterprise Architecture"

В допълнение към четирите основни типа корпоративна архитектура са възможни и други, съответстващи на други гледни точки, например:

ИТ архитектурата е структурата на набор от автоматизирани информационни системи (информационни технологии) на предприятие;

Бизнес архитектурата е архитектурата на предприятие, разглеждана без неговата ИТ архитектура.

4 Как да получите и използвате Enterprise Architecture

Ръководството на предприятието може да получи AP по два начина: първият е да разработи AP от персонала на предприятието, вторият е да се обърне към външни консултанти.

Първият път ще изисква управлението на предприятието:

формиране на работна група, която след това ще трябва да се трансформира в постоянна архитектурна служба на предприятието;

избор и придобиване на готови специализирани компютърна програмаза електронно моделиране на АП и обучение на специалисти от предприятието за използването му;

самостоятелно разработване и документиране на методическата поддръжка на АП;

самостоятелно развитие на AP.

Разработването на AP от външни консултанти ще изисква ръководството на предприятието да сключи договор за извършване на работа:

за прякото развитие на АП;

по разработването и документирането на методическата поддръжка на АП;

относно създаването на архитектурна служба на предприятието.

Компютърните програми за електронно моделиране на бизнес процеси и системни структури, които съществуват на пазара, позволяват да се конвертират бази данни с електронни модели от техните специализирани формати в www-формат и след това да се публикуват на вътрешния (интранет) сайт на предприятието. Това позволява реализиране

удобен и безлицензионен достъп за мениджъри и специалисти на предприятието до електронен модел AP.

Впоследствие формираната и подготвена архитектурна служба на предприятието може самостоятелно да реши проблемите на вариантите за моделиране на бъдещото състояние на AP в интерес на приемането от ръководството стратегически решенияза развитие на предприятието.

Списък на използваните източници

1. Зиндер Е. "3D-предприятие" - модел на стратегията на трансформираща се система. "Директор на информационно обслужване", бр.4, 2000г. http://www.sept2000.ru/articles/2008/03/03/1/.

2. Зиндър Е. Корпоративна архитектура в контекстбизнес реинженеринг. "Интелигентно предприятие / Корпоративни системи", № 4, № 7, 2008 г.

3. Галактионов В. Системна архитектура и нейното място в корпоративната архитектура. "Директор на информационно обслужване", бр.5, 2002г.

4. Данилин А., Слюсаренко А. Архитектура и стратегия. "Ин" и "Ян" на предприятията за информационни технологии. М.Интернет университет по информационни технологии, 2005г.

5. Дрожжинов В., Щрик А. Стандартизация на архитектурата на правителствените служби на САЩ. PC Week/RE. № 28, № 31, 2005 г.

6. Zachman John A. Рамката на Zachman.http://www.zachmaninternational.com/

7. Службата за управление и бюджет. Федерална корпоративна архитектура (FEA).http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Разширено Ръководство за основната рамка на корпоративната архитектура. Институт за развитие на корпоративната архитектура, 2006 г.http://www.enterprise-architecture.info/

9. Рамката за отворена групова архитектура (TOGAF).http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Обобщена корпоративна референтна архитектура и методология (GERAM). IFIP–IFAC, 1999 г.

11. Иванова И.А. Управление: Урок. - М .: Издателство РИОР, 2004 г.

Вече отбелязахме, че няма сингъл правилно определениекакво е корпоративна архитектура. Различни консултантски компании, индустриални асоциации, професионални асоциации използват малко по-различни концепции и методи, за да опишат това понятие. Нещо повече, тези концепции и методологии са в постоянен поток, така че опитът да се опише точно какво представлява корпоративната архитектура по начин, който отразява днешното мислене, е „стрелба по движеща се мишена“.

Най-общо казано, при разработването и използването на корпоративна архитектура, разбира се, препоръчително е да се придържате към всяка една методология, която би осигурила единство в подходите и подходящи набори от инструменти за описание на архитектурата. Преглеждаме накратко най-известните техники в „Техники за описание на архитектурата. Модели на Zachman и Gartner, техники на META Group и TOGAF“ и „NASCIO. Модели 4 + 1 и SAM. Техники на Microsoft и други. Избор на „оптимална“ техника“ . Тук описваме нашите Главна идеяотносно концепцията за корпоративна архитектура.

Архитектурата на предприятието е динамичен и мощен инструмент, който помага на организациите да разберат собствената си структура и как изпълняват своята работа и функции. Той предоставя „карта“ на предприятието и „план за маршрут“ за промяна както в бизнес, така и в технологичните области.

Обикновено корпоративната архитектура е под формата на доста широк набор от модели, които описват структурата и функциите на предприятието. Важна област на приложение на тези модели е систематизирането на процеса на планиране на информационните технологии и предоставянето на по-добри условияза процеса вземане на решение.

Индивидуалните модели на корпоративна архитектура са логически организирани, така че колективно да предоставят непрекъснато нарастваща ниво на детайлностинформация за предприятието - неговите цели и изпълнени задачи корпоративни програмии организационна структура, системи и данни, използвани технологии и всички други области на интерес.

Това е доста скучно и сухо определение на инструмент, който всъщност може да окаже огромно влияние върху решаването на сложни проблеми и да предостави нов поглед върху сложните и противоречиви ситуации, които постоянно се срещат в дейността на всяка организация. Корпоративна архитектура не се създава лесно. От друга страна, трудностите, свързани с това, не трябва да се преувеличават. Изводът е, че веднъж разработена, корпоративната архитектура може да донесе значителни ползи.

Архитектурата на предприятието е по-скоро процес, отколкото нещо статично. Няма да кажем, че създаването му е лесна забавна разходка. Но въпреки това може да бъде привлекателна и в известен смисъл омагьосваща дейност. Архитектурата на предприятието не е проста тема, но ние ще се опитаме да я направим по-малко "плашеща и обезсърчаваща" в това, което следва. Методите за описание на архитектурата на предприятието, които вече съществуват днес, позволяват да се организира съответният процес при наличието дори на минимално количество първоначална информация по интуитивен и естествен начин. В същото време пълнотата на описанието на архитектурата може да се увеличава постепенно, тъй като разбирането на обекта на описание на архитектурата расте - структурата и функциите на предприятието, както и поддържащите информационни технологии.

Когато проектирате корпоративна архитектура, трябва да се справите с голям брой измерения и връзки между тях, които трябва да бъдат взети под внимание. Следователно не е случайно, че много от техниките за описание на архитектурата, които ще разгледаме по-нататък, имат своите корени в такава дисциплина като системния анализ. Най-общо казано, разработването на корпоративна архитектура не е технически процес, който е свързан изключително с информационните технологии. Разбира се, за неговото развитие, като правило, подходящо технологични средства, но в по-голямата си част това са инструменти, които ви позволяват да създавате диаграми и текстове, т.е. софтуерни пакети, познати на повечето хора. Използването им е достатъчно прости инструментивъз основа на подходящи методологии обаче ви позволява да събирате основна информация за дейностите на организацията, да свързвате различни факти и да правите заключения, които опростяват и изясняват сложния процес на вземане на решения, който се повтаря в бизнеса всеки ден. По-важен е творческият компонент на този процес, който ще бъде разгледан в лекции 10-12.

Добрата корпоративна архитектура предоставя балансиран анализ на фактите за организацията и дава на ръководството начини да изследва своите организации и начина, по който работят, помага им да формулират нови стратегии и осигурява насока в процеса на планиране на развитието, за да поддържа организациите в съответствие с непрекъснато променящите се условия и приоритети. Говорим, разбира се, за средносрочни и дългосрочни хоризонти на планиране, както в бизнес, така и в технологичен план. Добрата корпоративна архитектура осигурява отзивчивост и гъвкавост, което се отразява в подходящите организационни форми, процеси, системи, портфолио от информационни и приложни системи.

Потребителите на корпоративната архитектура са доста голяма аудитория от специалисти и мениджъри:

• професионалисти в областта на създаването на информационни системи, които участват в съответните корпоративни проекти за създаване на приложения, които са важни за предприятието;
• системни архитекти, които отговарят за създаването на архитектурата на отделните информационни системи;
• бизнес анализатори, които ръководят процеса на проектиране на организационни структури и бизнес процеси;
• ръководители, които се интересуват от систематичен, структуриран анализ на проблемите и възможностите, които се отварят пред бизнеса.

Ако погледнете целите, които се преследват от различни подходи за описване на архитектурата на предприятието, тогава в успешни, правилни методи можете да намерите много общи неща:

• използване за анализ на множество гледни точки върху обекта на изследване (предприятието и неговите информационни системи) с цел „разделяне и владеене“ в процеса на борба с обективната сложност на реалния свят. Важно е да се разбере, че нито една гледна точка не е достатъчна, за да се разбере цялото;
• за да се осигури процес на синтез, всички модели, които са включени в архитектурата, са свързани с други модели. Те са или по-подробни декомпозиции, или свързани изгледи. Това богатство от връзки между моделите директно определя качеството на архитектурата.

И така, преди да продължите, ето още една дефиниция на корпоративната архитектура, която е дадена на уебсайта www.geao.org на „Организацията за глобална корпоративна архитектура“ (GEAO - Global Enterprise Architecture Organisation):

„Архитектурата на предприятието описва начините, по които цялостната визия на една организация се отразява в структурата и динамиката на предприятието. На различни нива на абстракция тя предоставя унифициран набор от модели, принципи, насоки и политики, които се използват за създаване , развиват и налагат системи в мащаб и контекста на цялото предприятие като цяло.

Имайте предвид, че терминът "система" тук не се отнася непременно за компютърна система– може да се отнася и до организационни структури, системи за управление и др. Но това определение само по себе си е доста абстрактно, така че ще се опитаме да му дадем все по-голяма степен на детайлност, докато го представяме.

В следващия текст използваме информация от няколко източника и се опитваме да я компилираме в рамките на някаква интегрирана концепция за корпоративна архитектура, която включва основните елементи на повечето методологии. По-специално, ние ще следваме препоръките.

Вече отбелязахме, че движещата сила зад корпоративната архитектура е холистична визия, която пресича организационните граници. Показано на фиг. 4.1, диаграмата, предложена от GEAO, илюстрира различните нива на абстракция, свързани с описанието на предприятието. Имайте предвид, че в рамките на една организация има само една корпоративна архитектура, но в същото време на ниво отделни системи може да има голям бройархитектури на решения. Архитектурата на предприятието обхваща както бизнес, така и ИТ аспекти, както и процесите на разработка, еволюцията на архитектурата и структурите за управление и контрол на тези процеси, които преминават от текущото състояние на архитектурата към желаното бъдещо състояние.

Виктор Галактионов, 20.05.2002 г
Списание "Директор ИС", №05, 2002 // Издателство "Отворени системи" (http://www.osp.ru/)

AT съвременни условияОсобено важно е постоянно и правилно да се привеждат в съответствие ИТ аспектите на дизайна на едно модерно автоматизирано предприятие с текущите бизнес аспекти. Това трябва да се направи, като се започне с дефинирането на бизнес архитектурата на предприятието и разработването на системната архитектура (ИТ архитектура), съответстваща на нея. В тази статия авторът споделя своя практически опит в разработването на системни архитектури за големи банки и дава конкретни съвети как това може да стане, включително и за предприятия от други индустрии.

Аз съм географ, не пътешественик. Пътуващите ми липсват. Не географите изброяват градове, реки, планини, морета, океани и пустини. Географът е твърде важен човек, няма време да се скита. Той не напуска кабинета си. Но той приема пътници и записва техните истории.

Антоан дьо Сент-Екзюпери. "Малкият принц". Глава 15. Географ

Известно е, че всеки бизнес модерна компаниявсе повече зависими от информационните технологии. Развитието на определени бизнес области, например развитието на "картовия бизнес" в банките, стана възможно само благодарение на появата на съвременни ИТ. Разбира се, това важи и за предприятията в други индустрии. Ето защо можем да се надяваме, че представеният опит може да се използва в бизнеса на всяка друга, небанкова компания, без значителни усилия за адаптиране.
Характеристиките на настоящото ниво на развитие на банковите информационни технологии се крият във факта, че в много банки, които успяха да запазят бизнеса си след кризата от 1998 г. и днес продължават активно да го развиват и увеличават, се въвеждат високотехнологични банкови решения срещу на фона на текущата операция. софтуерни системии комплекси от предишни поколения, често остарели. От друга страна, спиране на банковия бизнес дори за няколко часа, още по-малко спиране за един или повече дни за извеждане от експлоатация на остаряла софтуери пускането в експлоатация на нов, в повечето случаи ще е равносилно на загуба на бизнес. В тази ситуация във всеки един момент е необходимо да имате ясна представа за текущото състояние на всички внедрени и експлоатирани информационни системи, както и също толкова ясно разбиране за по-нататъшното им развитие, като се вземат предвид перспективите за развитието на банката, нейната архитектура като корпоративна архитектура. (В англоезичната литература - методи, статии, стандарти - това отговаря на термина корпоративна архитектура.)
Трябва да се отбележи, че корпоративната архитектура съществува самостоятелнокакто върху нашето съзнание, така и върху размера на това предприятие - независимо дали е глобална корпорация, малка фабрика, малка търговско предприятиеМалкото предприятие има същата архитектура като голямото, но те не се различават много по отношение на състава на компонентите. Някои мениджъри обаче разбират това и могат да си позволят да обърнат внимание на всички аспекти на организацията на собственото си предприятие (като правило това са ръководителите на големи компании), докато други не го правят. Друг е въпросът, че едно малко предприятие може да има само два или три продукта, мисията и стратегията не са изрично фиксирани (този проблем, между другото, е често срещан в големите компании), броят на служителите е 30 души и два компютъра с MS се използват в производството Word 97. Но дори и в този случай това е всичко, което съставлява архитектурата на това предприятие.
Статията представя доста подробен и в същото време прагматичен подход към организирането на работата по анализа на архитектурата на предприятието като цяло и планирането на архитектурата на системата, включително нейната документация. Основните цели на документирането на бизнес знания (разработване на корпоративна архитектура) са да се гарантира безопасността на инвестициите в бизнеса и прозрачността на бизнеса на всички нива.
Прозрачността на бизнеса започва с прозрачно разбиране на корпоративната архитектура, с ясно разделение на три взаимозависими нива: стратегическо ниво, ниво на бизнес архитектура и ниво на системна архитектура. Архитектурата на системата се определя от бизнес архитектурата и нейният дизайн може да се основава само на бизнес архитектурата, която от своя страна зависи от стратегията на предприятието. Този подход позволява, по наше мнение, не само да се организира правилно самата работа и да се направи правилно разделение на функциите и отговорностите на бизнес архитекта ("бизнес разработчик"), отговорен за развитието на бизнеса, тоест бизнес архитектурата на предприятието, и системния архитект, но също така, най-важното, да изгради балансирана корпоративна архитектура, която адекватно съответства на неговата мисия и стратегия.
Основните определения са дадени в началото на статията. След това се разглеждат съставът и съдържанието на системната архитектура, анализира се връзката между субектите на бизнес архитектурата и системната архитектура. Фазите и участниците в жизнения цикъл на системната архитектура, по-специално функциите на участниците, са разгледани достатъчно подробно. Накрая структурата на знанията, залегнали в основата на архитектурата на системата, е представена в съкратен вид и са направени окончателни заключения.

Основни понятия

Архитектура на предприятието- това е най-общото и изчерпателно представяне на едно предприятие, в случая банка, като икономически субект, който има краткосрочни и дългосрочни цели за извършване на основната си дейност, дефинирана от мисия в регионален и глобален мащаб, в нашия случай финансовият и кредитен пазар и стратегия за развитие, външни и вътрешни ресурси, необходими за изпълнение на мисията и постигане на поставените цели, както и установените правила за извършване на основната дейност (бизнес).
За целите на системния анализ архитектурата на едно предприятие може да се разглежда в два аспекта:

• статични - според състоянието на банката в определен момент от време;
• динамичен - като процес на преход (миграция) на банката от текущо състояние към някакво желано състояние в бъдеще.

Архитектурата на предприятието, разглеждана в статиката, се състои от следните елементи:

• мисия и стратегия, стратегически цели и задачи;
• бизнес архитектура;
• Системна Архитектура.

Архитектурата на предприятието, разглеждана в динамикае съгласуван, съгласуван план за действие и координирани проекти, необходими за трансформиране на текущата архитектура на организацията до състояние, определено като дългосрочна цел, въз основа на текущите и планираните бизнес цели и бизнес процеси на организацията.

Ориз. 2.

По този начин корпоративната архитектура в общия случай се описва от следните последователно зависими секции (виж Фиг. 1 и Фиг. 2):

• формулирана мисия и стратегия на банката, стратегически цели и задачи;
• бизнес архитектура в текущо (както е) и планирано (бъдещо) състояние,
• системна архитектура в текущо (както е) и планирано (бъдещо) състояние;
• планове за действие и проекти за преминаване от сегашното състояние към планираното.

На фиг. Фигура 1 показва, че изпълнението на плана за миграция не означава замразяване на развитието на бизнес и системна архитектура. По този начин планираната системна архитектура е архитектурата "да бъде" само на определен етап от развитието на предприятието. В същото време се върнете към стратегическо нивомисия и стратегически цели и задачи не означава необходимост от преразглеждане на мисията и стратегията. Но в края на всеки цикъл задължително се извършва анализ на ефективността на разработените и внедрени мерки, ако е необходимо, на втората итерация се коригира бизнес архитектурата, системната архитектура и се изпълняват нови планове за миграция. Може да има няколко цикъла във всеки момент от време, всеки такъв цикъл не засяга непременно цялото предприятие като цяло, цикълът може да засегне определени области, определени бизнес проблеми и може да бъде записан като отделен проект.
С план за поетапна миграция, за фиксиране на постигнатите резултати е възможно да се изгради междинна (миграция) една или повече архитектури.
Мисия, стратегия и бизнес целиопределя посоката на развитие на банката и поставя дългосрочни цели и задачи.
Бизнес архитектуравъз основа на мисията, стратегията за развитие и дългосрочните бизнес цели определя необходимата организационна структура, структурата на каналите за продажба и функционалния модел на банката, документи, използвани в процеса на разработване и внедряване на продукти. Функционалният модел описва бизнес процеси, насочени към изпълнение на текущи задачи и дългосрочни цели.
Бизнес архитектурата включва:

• продукти и услуги, предлагани и планирани за продажба от банката (включително индивидуални схеми за тяхното производство), формализирани под формата на единен регистър на продуктите и услугите, който също така съдържа клиентско сегментиране, тарифи и собственици на продукти;
• канали за продажба на продукти и услуги, изградени както на базата на структурни и териториални подразделения на банката, така и на базата на съвременни информационни технологии;
• функции и процеси за внедряване на външни и вътрешни продукти и услуги, формиращи дървета от функции и процеси (наричани по-нататък бизнес функции и бизнес процеси);
• финансови и административни документи (както на хартия, така и в в електронен формат), формализиран под формата на единен регистър (албум от формуляри) на банкови документи;
• дефинирани документни потоци регламентивърху вътрешния и външния документооборот;
• организационна структура, включително персоналбанка и нейните териториални поделения, които са самостоятелни стопански единици ( юридически лица), комитети, работни групи и ролеви функции на отделните служители, длъжностни характеристики, правилници за отдели и работни органи и други документи, регламентиращи взаимоотношенията и разпределението на отговорностите между банковите служители, както и между структурни подразделениябуркан.

Системна Архитектура(ИТ архитектура, корпоративна IS архитектура) - дефинира набор от технологични и технически решения за осигуряване на информационна поддръжкабанкова дейност в съответствие с правилата и концепциите, определени от бизнес архитектурата.
Освен това, под „решения“ имаме предвид, в зависимост от контекста, не само специфично оборудване и софтуер и информационни системи, но и принципите, стандартите и методологиите, използвани при разработването или избора на информационни и софтуерни системи, при избора и конфигурацията на оборудване.
Миграционни плановеопределя сценария на прехода на банката от сегашното състояние към обещаващо, определено от стратегически цели и задачи. Плановете за миграция определят трансформации както на бизнес, така и на системната архитектура. При поетапна миграция, с цел формализиране на междинни резултати, се разработват междинни (миграция) една или повече бизнес и системни архитектури. Плановете за миграция в съответствие с приетата от банката методология за управление на проекти се формализират като отделни проекти, включително по-специално:

• дефиниране на проект като набор от задачи и дейности;
• фази и срокове за изпълнение на проекта като цяло и задачите и дейностите, съставляващи проекта;
• анализ на конкурентната среда и рисковете, свързани с изпълнението на проекта;
• състава на разходните позиции на бюджета на проекта;
• критерии за успех на проекта и очакван икономически ефект.

Системна Архитектура

Архитектурата на системата се състои от три взаимосвързани компонента - архитектура на приложението, архитектура на данни и техническа архитектура (вижте Фигура 3). Архитектурата на системата в системата от стандарти на дадено предприятие определя правилата за формиране на нейните компоненти и осигуряване на взаимодействието между тях.

Ориз. 3.

Компоненти на системната архитектура

Архитектура на приложениетовключва:

• приложни системи (приложения), които осигуряват изпълнението на бизнес функции и бизнес процеси;
• интерфейси за взаимодействие на приложни системи една с друга и с външни системи и източници на данни или потребители;
• инструменти и методи за разработване и поддържане на приложения.

Архитектурата на данните включва:

• автоматизирани бази данни, които осигуряват натрупване, съхранение и обработка на данни, определени от бизнес архитектурата;
• системи за управление на бази данни или съхранение на данни, използвани за тази цел;
• правила и средства за разрешаване на достъп до данни.

Техническа архитектурасе състои от мрежова архитектура и архитектура на платформа.
Мрежова архитектуравключва:

• локални и териториални компютърни мрежи, включително физически собствени и наети комуникационни канали и каналообразуващо оборудване;
• комуникационни протоколи, услуги и системи за адресиране, използвани в мрежи;
• аварийни планове за осигуряване на непрекъсната работа на мрежите при извънредни ситуации.

Платформена архитектуравключва:

• компютърен хардуер - сървъри, работни станции, дискове и друго компютърно оборудване;
• Операционни и контролни системи, помощни програми и офис софтуерни системи;
• аварийни планове за осигуряване на непрекъсната работа на оборудване (главно сървъри) и бази данни при извънредни условия.

За решаване на проблемите на системната архитектура в състоянието на компанията, като правило, посветен Услуга за системен архитект. Тази служба отговаря за следните задачи:

• координиране на работата на ИТ отделите по документиране на текущата системна архитектура в началния етап и последващо поддържане на базата от знания за системната архитектура актуална;
• определяне на перспективни насоки за развитие на системната архитектура в съответствие със стратегическите цели и задачи на банката, детайлизирани под формата на перспективна бизнес архитектура;
• проектиране (съвместно с други специализирани отдели по информационни технологии) на обещаваща системна архитектура и планове за миграция от текущото състояние към бъдещето;
• формулиране на изисквания и ограничения към създадените или внедрени средства за автоматизация, които осигуряват качеството и целостта на архитектурата на системата;
• контрол на съгласуваността на системните архитектури, разработени в рамките на различни проекти;
• наблюдение на спазването на изискванията за осигуряване на качеството и целостта на системната архитектура от поделенията на банката, участващи в разработването, поддръжката и експлоатацията на информационните системи.

Отделно трябва да се спрем на един основен въпрос: кой разработва системната архитектура - системен архитект или разработчик на софтуер, технолог. Правилното решение е, когато отговорността за развитието на системната архитектура е възложена на ИТ отделите, които проектират, разработват, тестват, поддържат (включително извеждане от експлоатация) софтуерни и хардуерни системи и комплекси. Документацията за архитектурата на системата е част от задължителната проектна и експлоатационна документация. Този подход ви позволява да създадете малка услуга за системен архитект. В противен случай разработването на системна архитектура от специализирана услуга изисква значително увеличаване на броя на системните архитекти и процесите на разработка или се забавят значително, или разработената системна архитектура става неадекватна още в процеса на нейното развитие.

Връзки между системна архитектура и бизнес архитектура

Архитектурата на предприятието е напълно описана от следните обекти (вижте Фигура 4):

1. Мисия и стратегия на банката, стратегически цели и задачи.
2. Продукти и бизнес процеси.
3. Документите.
4. Организационна структура.
5. Приложения.
6. Данни.
7. Оборудване.
8. Планове за действие и проекти за преминаване от сегашното състояние към планираното.

Ориз. 4. Взаимовръзка на обекти от най-високото ниво на корпоративната архитектура

На фиг. 4 показва само обекти от най-високо ниво. Всеки от обектите се разпада на набор от по-подробни обекти. По този начин само обектът „Продукти“ в крайна сметка се разбива на повече от десет таблици, включително групи храни, тарифни планове, целеви сегментиклиенти и др.
Очевидно има силни връзки между всички тези субекти. Например внедряването на даден продукт е придружено от определени документи, подкрепени с информационна поддръжка от определени приложения и модули, които използват определени бази данни. Във внедряването на този продукт участват различни служители и отдели. Продуктът има собственик.

Ориз. 5. Архитектурата на предприятието и мястото на системната архитектура в нея

На фиг. Фигура 5 предоставя увеличено графично представяне на корпоративната архитектура и нейните дефиниращи компоненти.
Пример за ключови връзки между основните елементи на бизнес архитектурата и системната архитектура е показан на фиг. 6 под формата на ER диаграма.

Ориз. 6.

Същности и взаимоотношения на две архитектури

Жизнен цикъл на системната архитектура

За регулиране на жизнения цикъл (LC) на системите като цяло (включително предприятията), както и на техните информационни системи и софтуер (PS), в частност, има редица стандарти. Те предвиждат възможност за адаптиране на модели на жизнения цикъл, включително фази (етапи) към спецификата на конкретно предприятие и проект. По този начин фазите на жизнения цикъл, описани в този и следващите раздели, не противоречат на нормативните и не са догма. Предимството им по отношение на употребата в тази статия е простотата и опита на практическото приложение.

Ориз. 7.

Жизненият цикъл на системната архитектура се състои от следните фази: (вижте Фигура 7):

• първоначална документация;
• използване;
• дизайн;
• миграция.

ЗАБЕЛЕЖКА. След като фазата на миграция приключи, процесът се повтаря, следващата итерация започва с фазата на използване. Първоначалната фаза на документиране при разработването на нови ИС може да отсъства. Разработването на системната архитектура започва с фазата на проектиране.
По време на фазата на използване, еволюционно развитиеархитектура на системата в съответствие с предварително формулирани принципи и без промяна на основните технически и технологични решения.
ПРИМЕР. Нека системната архитектура на програмата за поддръжка бъде разработена на етапа на проектиране счетоводствов централния офис и клоновете и внедрен (фаза на миграция). Знанията за системната архитектура на това решение преминават в етап на използване, докато не възникнат нови бизнес изисквания за завършване / модернизиране на изградената система. Познаването на системната архитектура на създаденото решение се използва от компанията за изграждане на хранилище за данни с цел консолидиране на информацията и последващо получаване на управленски отчети. Но на базата на тези знания се проектира системната архитектура на хранилището за данни и след това системите за управление на отчети, които впоследствие, след като са преминали своите етапи на миграция, влизат във фазите на използване. По този начин можем да говорим за модел на многослойна системна архитектура, в който системната архитектура в различни слоеве може да бъде на различни етапи от жизнения цикъл (виж Фиг. 8).

Ориз. осем.

На етапа на проектиране се разработва обещаваща (бъдеща) системна архитектура, формулират се нови принципи за изграждане на системна архитектура и се разработват нови основни технически и технологични решения в съответствие с тези принципи. Обикновено причината за изпълнението на тази фаза е значителни променив бизнес архитектурата, появата на нови бизнес изисквания, които значително влияят на системната архитектура.
На фазата на миграция се извършва набор от организационни, технически и технологични мерки, за да се осигури преходът на архитектурата на системата от текущото състояние към обещаващо състояние или към следващото междинно състояние по време на поетапна миграция в съответствие с плановете за миграция, изготвени в предишната фаза.
Жизненият цикъл на системната архитектура е свързан с жизнения цикъл на софтуера. Жизненият цикъл на софтуерните инструменти (PS) се състои от следните основни фази:

• предпроектно проучване;
• разработване на технически спецификации;
• развитие технически проект;
• разработване и документиране на ПС;
• PS тестване;
• въвеждане на ПС;
• експлоатация на подстанцията;
• извеждане от експлоатация на ПС.

Архитектът на системата контролира дизайнерските решения през целия жизнен цикъл на софтуера. Контролът се извършва под формата на съгласуване на проектни документи, изготвени и изпратени на системния архитект от отдели, отговорни за изпълнението на една или друга фаза от жизнения цикъл на PS.
Представени са описания на фазите на жизнения цикъл на системната архитектура, обхвата на работата по системната архитектура, извършена във всяка фаза, изпълнителите на тези работи, както и съответствието на фазите на жизнения цикъл на PS. По-долу.

Първоначална документация

Фазата на жизнения цикъл на системната архитектура "Първоначална документация" няма пряко съответствие във фазите на жизнения цикъл на софтуерните инструменти. Съдържателно тази фаза е представена от функциите на нейните активни участници (виж табл. 1).

Маса 1.

Използване

Следните фази от жизнения цикъл на софтуерните инструменти съответстват на фазата на жизнения цикъл на системната архитектура „Използване“:

• Разработване на техническо задание за ПС.
• Разработване на техническия проект на ПС.
• PS тестване.

(Вижте бележка, Фиг. 8 и примера по-горе. От примера виждаме, че разработването на TOR, TP, тестването и внедряването на хранилището на данни и системата за отчитане на управлението използва знания за системната архитектура на счетоводната система в търговска експлоатация , и чиято системна архитектура в момента е във фаза на използване, докато архитектурата на системата за съхранение на данни в момента е във фаза на проектиране.)
Функциите на активните му участници във фаза „Използване” са представени в табл. 2.

Таблица 2.

Дизайн

Тук може да възникне въпросът: къде отиде развитието на постановката на проблема? И нужен ли е изобщо? Фазата от жизнения цикъл на системната архитектура "Дизайн" съответства на следните фази от жизнения цикъл на софтуерните инструменти:

• Изготвяне на технически спецификации за ПС.
• Изготвяне на техническия проект на ПС.

Разбира се, ние се нуждаем, казано на официален език, от фазата „Анализ на обекта на автоматизация“, включително разработването на формулировка на проблема, формулирането на бизнес изискванията и, разбира се, има такава фаза. Подробното обсъждане на тези въпроси обаче е извън обхвата на статията, която е ограничена до разглеждане на системната архитектура.
Нека все пак обясня. Необходимостта от промяна на бизнеса и в резултат на това необходимостта от преструктуриране на бизнес архитектурата може да се дължи на:

1. промени в мисията или стратегията;
2. промени в пазарната ситуация;
3. регулаторни органи.

След осъзнаването на тази необходимост се появява формулирането на бизнес изискванията, но всичко това се случва, докато все още сме в слоя на бизнес архитектурата (виж Фигура 4). Стрелките от обектите „Продукти“ и „Документи“, насочени към обектите „Оборудване“, „Програми“ и „Данни“, съответстват на постановката на проблема (бизнес изисквания). Нека се върнем към нашия пример, от който виждаме, че разработването на TOR, TP, тестването и внедряването на хранилище на данни използва знания за системната архитектура на счетоводна система, която вече е в търговска експлоатация и нейната системна архитектура в момента е в използва фаза. Системната архитектура на хранилището на данни в момента е във фаза на проектиране (вижте Фигура 8).
Функциите на активните участници във фаза „Проектиране” са представени в табл. 3 .

Таблица 3

миграция

Фазата от жизнения цикъл на системната архитектура "Миграция" съответства на следните фази от жизнения цикъл на софтуерните инструменти:

• Тестване на софтуер.
• Внедряване на софтуер.

Функциите на активните участници във фаза „Миграция” са представени в табл. четири .

Таблица 4

По този начин системната архитектура е наистина засегната в следните фази от жизнения цикъл на софтуера:

• На фаза "Разработване на технически спецификации за PS"извършва се анализ на съществуващата системна архитектура с цел възможността и целесъобразността за използване на съществуващите ресурси за решаване на новопоставени бизнес проблеми. Освен това при изготвяне на техническото задание винаги, когато е възможно, се вземат предвид изискванията и ограниченията, наложени от съществуващата системна архитектура.
• На фаза "Разработване на техническия проект на ПС"извършва се фактическото формиране или промяна на архитектурата на системата, което е необходимо за изпълнение на новопоставените бизнес задачи. Изискванията и ограниченията, наложени от съществуващата системна архитектура, се вземат предвид, за да се осигури непрекъснатост и да се минимизират разходите за надграждане.
• На фазите "Тестване" и "Внедряване"на разработения софтуер, изискванията на системната архитектура се използват за формиране на необходимата технологична среда за тестване и работа на тези ПС.

Съставът на базата от знания за системната архитектура

Тъй като само списъците с това, което трябва да знаете за системната архитектура, са много големи за представяне в статия в списание (те възлизат на десетки позиции), по-долу са описани само раздели от съответната база знания и се прави опит поне да се очертаят съдържанието на тези раздели.
Базата от знания за системната архитектура трябва да се състои от поне три раздела:

1. Текуща системна архитектура.
2. Перспективна (планирана) системна архитектура.
3. Миграционни планове.

Разделите „Текуща системна архитектура“ и „Бъдеща системна архитектура“ имат еднаква структура и се състоят от следните подраздели:

1. Принципи на изграждане на системна архитектура.
2. Основни технически и технологични решения.
3. Изисквания и стандарти.
4. Приложна архитектура.
5. Техническа архитектура.
6. Архитектура на данни.

Принципи на изграждане

Дадени са изискванията и ограниченията, наложени към системната архитектура от страна на бизнес архитектурата. Посочени са всички изисквания и ограничения - както формулирани директно в бизнес архитектурата, така и допълнителни, формулирани от системния архитект.
Дадено е описание на принципите за изграждане на системна архитектура, произтичащи от горните изисквания и ограничения.

Основни решения

Описани са основните технически и технологични решения, които са в основата на архитектурата на системата. Например, може да бъде решение да се използва компютърът AS/400 като основна хардуерна платформа на информационната система на банката или решение да се използва DB2 DBMS като основен инструмент за управление на информационните ресурси на банката.
Всяко решение е придружено от коментар, обясняващ как това решениесъответства на формулираните по-горе принципи за изграждане на системна архитектура.
Основните решения, взети при проектирането на архитектурата на системата, се оформят в отделни документи, с кратко обобщение на предисторията, същността на проблема и приетото фундаментално решение на проблема, което е задължително в бъдеще при проектиране, разработване и внедряване на информационна система.

Изисквания и стандарти

Посочват се всички изисквания, стандарти и ограничения, на които отговаря системната архитектура. Ако е необходимо, отделни стандарти (изисквания, ограничения) или препратки към тях могат да бъдат дублирани в следващите глави.
Дават се препратки (код, име, издание и др.) към външни стандарти. При необходимост се дават пълни или частични текстове на външни стандарти.
Вътрешните стандарти (стандартите на предприятието) са описани, като се посочва кодът (ако е зададен), името, изданието и одобряващият орган.
Описани са допълнителни изисквания и ограничения, на които трябва да отговарят елементите на системната архитектура и информационната инфраструктура, които не са получили статут на стандарт.
Обяснява се кои конкретни принципи на изграждане на системна архитектура или възприети основни технически и технологични решения са наложили използването / съобразяването с този стандарт / изискване или ограничение.

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

Описват се приложни системи (приложения), които осигуряват изпълнението на бизнес функции и бизнес процеси и тяхното взаимодействие. Нивото на детайлност на описанието трябва да съответства на програмния модул, разбиран като програмна единица, независимо съхранявана като файл или раздел на библиотеката.

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

Мрежова архитектура

Съдържа описание на териториалната комуникационна инфраструктура и локалните мрежи (LAN).

Платформена архитектура

Съдържа описание на операционни системи и оборудване отделно за сървъри и работни станции.

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

Бази данни и хранилища на данни

Съдържа описание на бази данни и организирани по друг начин информационни масиви.

Системи за управление на бази данни

Съдържа описание на използваните системи за управление на бази данни.

План за миграция

Съдържа план за миграция от текущата системна архитектура към бъдещата.
Ако се очаква поетапна миграция, тогава тук са включени и междинни планове за миграция.
Както бе споменато по-рано, планът за миграция е формализиран като чернова. Така за всеки план разделът включва всички документи, предвидени от методологията за управление на проекти на Банката, както одобрени, така и такива в процес на разработване или одобрение.

Заключение

По-горе показахме, че съставът и съдържанието на знанието за системната архитектура е дълбоко структуриран набор от силно взаимосвързана информация. Освен това връзките не се ограничават до връзки между обектите на системната архитектура (виж Фиг. 3), но също така са тясно свързани с обектите на бизнес архитектурата. Така че на практика често се налага да се намери отговор на следните въпроси:

• Кой в банката изпълнява тази или онази бизнес функция, колко редовно го прави, какво събитие задейства изпълнението на тази бизнес функция, автоматизирано ли е или не, или е изпълнението на тази бизнес функция?
• Каква информация се въвежда за определена бизнес функция, кой е доставчикът на тази информация, под каква форма идва?
• Какви софтуерни инструменти се използват за изпълнение на определена бизнес функция, какви други ИТ функции изпълняват тези програми, какви бази данни и директории се използват, какви екрани и какви отчети се генерират от програмата?
• Каква информация е входяща и изходяща за конкретна програма, под каква форма постъпва входящата информация и се формира изходящата?
• Как е организирано информационното взаимодействие на две програми: чрез формиране / четене на файл, директно чрез API, чрез електронна поща, чрез системи на ниво междинен софтуер, каква е структурата на обмена на информация, каква е честотата?
• Кои отдели използват определена програма, кой трябва да бъде уведомен, когато се промени програма или някаква наредба?
• Използва ли се в момента тази или онази ИТ функция на програмата, от кого, колко често?

Разбира се, има и много други проблеми, които по някакъв начин са свързани със системата и бизнес архитектурата.
Поради ограничения размер на статията в списанието, анализът на тези въпроси е извън неговия обхват. Отбелязваме само, че за структурирането и документирането на тези знания възможностите на MS Word или MS Excel са незаменими. Трябва да използвате по-напреднали софтуерни системи, но още по-важно е използването на подходящи техники или дори методологии. Една от тези насоки, която според опита на автора отговаря на необходимите изисквания, е "ARIS методологията" (ARchitecture of Integrated Information System). Това обаче е съвсем друга тема, може би за друга статия.

В много отношения обосновката за необходимостта от разработване на модел на бизнес архитектура е свързана с разбирането на факторите, които тласкат предприятието да търси решения за оптимизация в областта на организирането на дейности. Тези фактори могат да включват макроикономически тенденции, конкурентна среда, промени в бизнес стратегиите и т.н. Познаването на тези фактори и свързването им с възможностите за решаване на проблеми на моделирането на бизнес архитектурата е от решаващо значение за подпомагане на проекта с висшето ръководство на организацията.

Проблемът с обосноваването на необходимостта и бюджетите на проект за създаване на модел на бизнес архитектура е свързан не само с идентифицирането на "движещите" фактори, но и със сложността на обосноваването на очакваните ефекти. В много случаи в началния етап е възможно да се декларират само прогнози за косвено подобряване на бизнеса на организацията, които трудно могат да се съпоставят с ясно дефинирани финансови ползи. Дори в случай на настъпване на събития с количествено измерими ефекти, доказателство за пряката връзка на тези събития с изграждането и внедряването на модел на бизнес архитектура в процеса на управление на една организация не винаги е възможно.

Трудно е да се дадат някакви общи подходи за обосноваване на очакваното икономически ефектипоради появата на действителен модел на бизнес архитектура в организацията. В много отношения крайната печалба се определя от уникалността на ситуацията на всяка отделна организация. Това може да бъде успешен реинженеринг на бизнес процеси, оптимизиране на информационната и технологична инфраструктура, намаляване на времето и разходите за получаване на първоначални данни при стартиране на проекти и т.н., реализирани въз основа на използването на модела.

В най-общия подход ефектите от създаването на модел на бизнес архитектура трябва да се позиционират с повишаване на общата управляемост на предприятието. По отношение на ИТ компонента на корпоративната архитектура световната практика показва възможност за намаляване на разходите на служител с до 30%, докато липсата на документирана ИТ архитектура води до допълнителни разходи до 12-18% в редица оперативни области.

Ако е необходимо да се получат оценки за „интегралните“ ефекти от внедряването на модела на бизнес архитектурата, вземането предвид само на финансовите ползи няма да е достатъчно, за да оправдае инвестицията. Следователно ще е необходимо да се използват по-сложни механизми за сетълмент, включително „нефинансови“ ефекти, които са значими за дейността на организацията. Този тип ефекти трябва да включват минимизиране на рисковете по време на различни промени в дейностите на организацията чрез използване на възможностите на модела на бизнес архитектурата за симулиране на различни сценарни опции, включително получаване на различни качествени и количествени оценки. Като се има предвид високата динамика на промяна и сложност модерна организация, въпросите за минимизиране на рисковете, свързани с проблемите на преструктурирането, са от особено значение.

Характеристика на инвестиционните проекти за създаване на модел на бизнес архитектура е доста дълго време за изчакване за ясно наблюдавани ефекти. До известна степен тук можем да направим аналогия с очакванията за възвръщаемост на разходите за обучение на персонала за подобряване на цялостната информационна или проектна култура. Като част от обосновката за ефективността на архитектурата на ИТ компонентите в момента се разглеждат възможностите за използване на показатели като възвръщаемост на активите (ROA) и възвръщаемост на възможностите.

Един от първоначалните стандартни въпроси от ръководителите на организацията, които преди това не са били запознати с възможностите и задачите на моделирането на бизнес процеси, е да се изяснят очакваните ползи от резултатите от консултантската работа по моделиране.

Често стандартните отговори на тези въпроси са свързани с акцент върху оптимизирането на бизнес процесите на организацията и съответно изброяване на "базов набор" от параметри за оптимизация:

♦ дублиране на функции;

♦ тесни места;

♦ разходни центрове;

♦ качество на отделните операции;

♦ излишни транзакции;

♦ възможности за автоматизация;

♦ възможността за въвеждане на системи за управление на качеството;

♦ възможност за сертифициране по ISO 900x.

При цялата коректност на тези отговори трябва да се признае, че от гледна точка на последователността на работа и постигането на резултати те не са първостепенни.

Съвсем независим, важен и първи за постигане е резултатът относно подреждането и документирането на знанията за организацията. Като част от изграждането на модел неизбежно възникват следните процеси:

♦ инвентаризация и извличане от различни източници (включително отделни квалифицирани служители) на информация (знания), специфична от гледна точка на дейността на организацията;

♦ структуриране и систематизиране на извлечената информация, като се вземат предвид основните цели и задачи на организацията;

♦ формализиране и документиране на информация (знания) за организацията.

Очевидно, независимо от целите на оптимизацията, качественото натрупване, структуриране и формализиране на информация (знания) са много важни от гледна точка на:

♦ технологична подкрепа за процесите на съхранение на ноу-хау на организацията;

♦ намаляване на зависимостта от ключови експертни ресурси за трансфер на знания и компетенции към нови служители;

♦ повишаване нивото на управляемост на организацията чрез формализация изисквания за работаи инструкции за персонала.

Като правило, след систематизиране и формализиране на знанията за текущото състояние на дейността на организацията, дори преди описването на процесите и избора на метод за тяхната оптимизация (реинженеринг), въз основа на специализирани инструменти за моделиране се идентифицират организационни и технологични резерви. които могат да се използват за подобряване на ефективността на организацията.

На етапа на систематизиране и формализиране се извършва действителната проверка на наличието и яснотата на дефиницията и, ако е необходимо, изясняването на такива важни за организацията данни като:

♦ задачи;

♦ показатели за изпълнение;

♦ регламенти (инструкции, заповеди и др.) на бизнес процесите.

В редица случаи може да се каже, че нормативните насоки са толкова изпълними и проверими по отношение на качеството на изпълнение, колкото и формализирани. В този смисъл на етапа на систематизиране и формализиране се проверява „работоспособността” на целите и регламентите (стандартите).

Следователно правилният отговор на потенциален клиент на въпроса „защо се нуждаем от модел“ на бизнес архитектурата на организацията е да посочи поне два фундаментално важни резултата (цели):

♦ систематизиране и документиране (формализация) на важната за дейността информация (знания), което осигурява:

а) технологична основа за вътрешнокорпоративно запазване и наличие на специализирани знания (ноу-хау) на организацията;

б) повишаване нивото на управляемост на ресурсите на организацията поради качественото формализиране на правилата за тяхното използване (фиг. 1);

Ориз. 1. Проблеми на управлението на знанието в организацията по отношение на бизнес процесите

♦ създаване на методологична и технологична основа за поетапна оптимизация (реинженеринг) на организацията, която позволява техническа и икономическа оценка на мерките за модернизация, идентифициране на организационни, функционални и технологични резерви за подобряване на ефективността на организацията (фиг. 2).

Ориз. 2. Обещаващи решения за използване на знания за бизнес процесите при вземане управленски решения

Един от допълнителните аргументи в полза на необходимостта от моделиране на бизнес архитектурата на организацията са световните тенденции за стандартизиране на изискванията за задължително наличие на модели на бизнес процеси на организацията. Доказателство за тези тенденции е появата на специализирани стандарти и методологии за проектиране на корпоративна архитектура.

Като основни методологии и стандарти трябва да споменем „рамковите“ стандарти за разработване на корпоративна архитектура;

а) ISO 15704 - стандарт за формално описание на архитектурата на предприятието, предложен от работната група IFAC / IFIP (Международна федерация за автоматично управление / Международна федерация за обработка на информация);

б) ISO 15288 е стандарт, който определя кръговат на животасистеми;

в) ISO 12207 е стандарт, който определя жизнения цикъл на софтуера.

Има над 30 допълнителни "поддържащи" системи и стандарти за софтуерно инженерство (напр. ISO 14258, определящ концепциите и правилата за корпоративно моделиране).

Разработването на модел на бизнес архитектура е една от логичните следващи стъпки за онези организации, които са започнали да прилагат концепцията за ориентирана към услуги архитектура (SOA). В основата си SOA отразява характеристиките на настоящата съвременна ситуация във взаимното проникване на ИТ и бизнеса, когато е изключително трудно да се направи граница между бизнес функциите на организацията и информационните технологии, които ги осигуряват.

От гледна точка на поддръжката на SOA, моделът на бизнес архитектурата е основният инструмент за синхронизиране на бизнес нуждите и възможностите на информационните технологии. Моделът на бизнес архитектурата носи основната тежест за осигуряване на условия за процесен подход при проектиране и оптимизиране на самата бизнес архитектура на организацията, следван от ИТ дизайна. Според концепцията на SOA, бизнес архитектурата трябва да се основава на процесно-ориентиран модел на предприятието. Комбинацията от този подход с концепцията за ориентирана към услугата архитектура на информационните технологии ви позволява по-добре да свържете процеса на разработване на компоненти на информационни системи с мисията, основните задачи и функции на организациите. Със SOA организациите имат потенциала да разработят набор от реализации на различни бизнес процеси, които могат да бъдат използвани повторно от предприятието като готови услуги.

Изявленията на задачите за моделиране на бизнес архитектура в контекста на поддръжката на SOA са насочени към осигуряване на следните изисквания за проектиране на IS:

♦ изрично разделяне на бизнес логиката на прилаганата система от логиката на представяне на информацията;

♦ реализиране на бизнес логиката на приложната система под формата на множество програмни модули (услуги), които са достъпни отвън (на потребителите и други модули), най-често в режим "заявка-отговор", чрез добре- дефинирани официални интерфейси за достъп.

В същото време „потребителят на услугата“, който може да бъде приложна система или друга услуга, има възможност да извика услугата чрез интерфейси, използвайки подходящите комуникационни механизми, а също така ясно позиционира своето място в бизнес процеса.

В допълнение към „осигуряващата“ роля, а именно подкрепа за внедряването на концепцията на SOA, моделът на бизнес архитектурата има самостоятелно значение и съответните дефиниции на задачите. Висока динамика на промените в околната среда модерен бизнес, не може да не окаже силно влияние върху скоростта и обхвата на развитие на бизнес моделирането. Правенето на дългосрочни прогнози въз основа на стабилността на ситуацията не е възможно в почти никоя област на бизнеса. Напротив, компаниите трябва да се адаптират към непрекъснато променящата се среда и да развият умения за бързо адаптиране към текущите бизнес промени. В тази връзка в момента се разработват концепции за организации, които съдържат специални вътрешни механизми, които им позволяват да се променят в съответствие с изискванията на външната среда.

Нарастващата роля на бизнес моделирането се определя не само от високата динамика на средата на "жизнената дейност" на организацията, но и от обстоятелствата, че има ресурс от възможности за ефективно реагиране на "предизвикателствата" на пазара само с помощта на ИТ. е значително намалена. Все по-често се чуват твърдения, че хаосът не може да бъде автоматизиран, че автоматизацията на хаоса е още повече хаос, че модерните ИТ не могат да се считат за панацея за всички бизнес проблеми.

Основните резерви за повишаване на ефективността и конкурентоспособността на предприятията в момента са свързани с оптимизирането на тяхната бизнес архитектура, последователното прилагане на модела за управление на процесите и осигуряването на гъвкавост. организационна структураи бизнес процеси, свързани с управлението на добавената стойност и др. Тези възможности до голяма степен се предоставят от детайлна бизнес архитектура на компанията, която трябва да съдържа описание на процесите на промяна в организацията на дейността на компанията, както и да предоставя ефективно управлениетези процеси.

Разработването на модел на бизнес архитектура позволява на предприятието да получи универсален инструмент, който допринася преди всичко за осъзнаването на собствената му структура и методи на организация. производствени процеси. Този модел ви позволява да формирате план за насърчаване на организацията в областта на бизнеса и нововъзникващите технологии.

Добре проектираната архитектура може и трябва да се използва от ръководството на предприятието, за да се проучат принципите на неговото функциониране, а също така дава възможност за разработване на нови, по-напреднали стратегии, организиране на нови начини за планиране на развитието, като се вземат предвид необходимост от постоянно променящи се външни условия (разбира се, говорим за планиране в средносрочен и дългосрочен план). Такава архитектура позволява бърза реакция и гъвкавост, което се дължи на избора на подходящи форми на организация, специалното развитие на процесите и използването на определени класове информационни системи.

В подкрепа на тези тези относно ролята и мястото на бизнес моделирането можем да цитираме изказването на анализатора на Gartner Джим Синур (Jim Sinur): modeling lately”. Като цяло трябва да се отбележи, че за различни експертно мнениеповечето предприятия ще ръководят проекти, които по един или друг начин ще засегнат различни аспекти на проблема за подобряване на бизнес процесите, въпреки смесените оценки на практиката за реинженеринг на бизнес процеси от средата на 90-те години.

В допълнение към методологичните иновации и тенденции в развитието на бизнес организацията и ИТ, развитието на пазара за нуждите на бизнес моделирането е значително повлияно от модерни подходичрез оценка на нивото на развитие (зрялост) на организацията. В рамките на тези подходи моделът на бизнес архитектурата е задължителен компонент за оценка на организацията.

Като пример за методологията, използвана в развитите страни за оценка на зрелостта на публичните организации, можем да цитираме модела на Администрацията за финансов контрол на САЩ, който определя пет нива на зрялост.

Използването на бизнес модел в дейността на организацията отваря широки възможности за качествена и количествена оценка на нейната ефективност, включително използването на общоприети (стандартизирани) методологии и инструменти. Всъщност бизнес моделът ви позволява да осигурите измеримостта на ключовите характеристики на организацията чрез използване на подходящи метрики: метрики за оценка на „качеството“ на самия процес, метрики за оценка на преките резултати (изход), метрики за оценка на крайните резултати .

Метриките на ниво процес измерват ефективността на самия процес. Типичните показатели са време на цикъл, цена на транзакция или резултат от процеса. Метриките за резултат оценяват способността на процесите да произвеждат продукт или услуга като изход според спецификациите. Типичните показатели за оценка на преките резултати са процентът на грешките и броят заявки, обслужени за единица време. Метриките за оценка на резултатите оценяват процеса от гледна точка на крайния потребител (клиент) и изпълнението на функциите на организацията.

Очевидно е, че поставянето на задачи за моделиране за производствена (търговска) организация може значително да се различава от задачите на държавния контролен (надзорен) орган. Поради тази причина, разбира се, е необходима специфична настройка на всеки от методите на високо ниво към областта на моделиране. Пазарът на консултантски услуги отговаря доста адекватно на тази нужда. И така, в момента има практически значими модели за различни сектори на икономиката и държавни агенции, които се изпълняват на базата на различни методологии и инструменти за моделиране, като методологията ARIS и семейството софтуерни продукти IDS Sheer AG, базирани на нея, езика UML моделиранеи инструмент за разработка на обектно-ориентирани информационни системи Rational Rose от IBM, IDEF методология, DFD и AllFusion Modeling Suite (по-рано BPwin и ERwin) от Computer Associates и др.

Несъмнено, когато предприятието поставя задачи по свой начин, международна сертификацияи навлизането на пазарите на развитите чужди страни, разработването на модели на бизнес процеси е особено актуално. Поради тази причина започването на тези работи в предприятието не е „почит“ към новата „мода“. Несъмнено създаването и последващата поддръжка на модели не само ще положително влияниевърху цялостния имидж на организацията, но също така ще помогне за подобряване на цялостната управленска и производствена култура на предприятието. До известна степен събуждането на интереса на органи държавна власт(OGV) и бизнес общността към моделирането на бизнес процеси може да се сравни с по-ранния и широко използван процес на въвеждане на методи и технологии за управление на проекти.

Трябва да се отбележи, че ОГВ на Руската федерация, които отговарят за формирането на научно-техническата политика в различни области, провеждането на административни реформи, реагираха доста „чувствително“ на горните глобални тенденции и определиха целеви задачи за тяхното разглеждане в Руската федерация.

Състоянието на формализация и въз основа на това оптимизиране на административните и управленските процеси на OGV е определено в документа „Стратегия за развитие и използване на информационните и комуникационни технологии в Руската федерация“ като основни показатели за планираните дейности. Таблицата по-долу отразява текущото състояние, перспективите и държавната политика за въвеждане на бизнес моделиране в дейността на OGV на Руската федерация (Таблица 1).

Подобно повишено внимание на държавните органи на Руската федерация към проблема с въвеждането на формализирани механизми за описание на дейността на държавните организации е напълно оправдано. Въпреки факта, че поради своята специфика държавните организации имат по-голяма (в сравнение с търговските структури) инертност и селективност при реагиране на пазарните промени, текущата "натрупана маса" от потребности е достигнала критична точка.

Понастоящем управленското и изпълнителско ниво на публичните организации често е изправено пред много по-сериозни проблеми от търговския сектор. На първо място, това е необходимостта от задължително използване в своята дейност на нормативната и правната рамка, която е доста обширна, сложна и често позволява двусмислено тълкуване. Броят на законовите и подзаконовите актове от федерален и ведомствен характер е стотици и хиляди, броят на видовете оперативни документи и данни, които подлежат на обработка в някои министерства и ведомства, достига няколкостотин. Често изпълнението на процесите е организирано по такъв начин, че един служител има натовареност, която надвишава разумните стандарти, като в същото време той носи сериозна административна и наказателна отговорност. При тези обстоятелства създаването на условия за ефективна и законосъобразна работа на държавните служители е изключително актуална задача, за чието решаване държавата предприема съответните стъпки:

♦ въвеждат се електронни административни разпоредби;

♦ формират се механизми за информационна и консултантска подкрепа;

♦ оптимизира се организационната структура.

Това се потвърждава от административната реформа, инициативите за широкомащабно въвеждане на електронни административни регулации, формирането на електронно правителство и др. Във всички тези проекти формирането и оптимизирането на бизнес моделите е предварителен процес, който определя основния начален данни.

Свързан с въпроса "защо имаме нужда от модел" е въпросът "кому е нужен" модел. Въпрос на дефиниция потенциални потребители(потребители) на модела е ключът към специфицирането и детайлизирането на целите. Моделирането на бизнес процеси може да обхване различни аспекти на предприятието: основната и формираща инфраструктура на предприятието. Съответно, кръгът от заинтересовани лица под формата на ръководители и изпълнители ще се определя от посоката на дейността на организацията, избрана (избрана) за моделиране.

На ниво подразделения на предприятието като заинтересовани потребители на модела могат да действат: административен апарат, отдели за информационни технологии, отдели за персонала, правни отдели и др.

В същото време доста голяма аудитория от специалисти и мениджъри могат да действат като потребители на модела на бизнес архитектурата на предприятието в отделите:

♦ бизнес анализи в различни области на предметната (целевата) дейност на организацията;

♦ разработчици на информация и технологични системи;

♦ системни архитекти, които отговарят за създаването на архитектурата на отделните информационни системи;

♦ бизнес анализатори, които ръководят процеса на проектиране на организационната структура;

♦ мениджъри, които се интересуват от систематичен, структуриран анализ на проблемите и възможностите, които се откриват пред бизнеса и др.

По принцип инициативата за моделиране на бизнес процеси може да дойде от всеки отдел на предприятието. Това зависи от нивото на информираност на ръководителите на отдела за възможностите и полезността на моделите, приоритета на текущите задачи за оптимизиране на дейностите, пълнотата на моделиране на отделните бизнес процеси на предприятието.

В действителност в повечето случаи инициативата за разработване на модели на бизнес процеси идва от отделите за информационни технологии на организацията. Това се дължи на необходимостта от автоматизиране на определени сфери на дейност на предприятията на фона на обща висока активност при внедряването на ИТ във всички сфери на бизнеса и все по-голям дял на бюджетите на предприятията за ИТ компонента.

С цялата положителна страна на самия факт на дейността на ИТ отделите (както и на всеки друг функционален отдел) при прилагането на бизнес моделиране, правилно е да се запази инициативата и контролът върху този процес за висшето ръководство на организацията. Така ще се избегне „тясно ведомствен” чисто ИТ (или друг) подход към моделирането, насочен към постфактум решаване на конкретна задача – автоматизиране на отделен процес и предоставяне на решение на корпоративна задача – създаване на инструмент за оценка и оптимизиране на бизнеса процеси в рамките на постигане на целите за ефективност на цялата организация.

Поддръжка и общо управлениеЧрез въвеждането на модел на бизнес архитектура в едно предприятие те не изключват или намаляват ролята на функционалните звена в тази работа. Колкото „по-широк“ и „по-дълбок“ става моделът, колкото „по-близо“ е до потребителя, толкова по-голям брой заинтересовани страни се появяват в неговото развитие и поддръжка.

В резултат на моделирането на дейността на предприятието в рамките на процесния подход „неизбежно“ има постепенно (тъй като моделът е детайлизиран) показване на ролята, мястото, ефекта, въведен от всички организационни и персонални структури на предприятието . Поради тази причина, като се гарантира, че значимостта на единицата е адекватно отразена в общ моделпредприятия, както и последващото търсене на увеличаване на "приноса" към целевите резултати на предприятието или "намаляване" на разходите на звеното, ще провокира ръководителите на тези звена да участват активно в изграждането на модел на бизнес архитектура.

До известна степен въпросът „кому е нужен бизнес модел” може да се сравни с въпроса „кому е нужен електронен документооборот". От един момент нататък работният процес се използва от всички и всеки отдел участва в поставянето на задачи за създаване на специализирани електронни регламенти за поддръжка на "своята" част от работния процес и тяхната "ревностна" защита, а по отношение на бизнес моделирането, всеки отдел започва да изгражда "своя собствена част" модел на бизнес архитектура на голяма сграда.

Поставянето на цели, внедряването, внедряването и мащабирането на резултатите от проектите за моделиране на бизнес процеси са важни етапи в промяната на цялостната корпоративна култура на едно предприятие. Служителите постепенно придобиват знания, умения и опит за процесния подход при осъществяване на своята дейност, ясно се позиционират в сложната структура на организацията, овладяват съвременни методи за оценка на резултатите от своята работа и намиране на начини за нейното оптимизиране.

Създаването на модел на бизнес архитектура е вид колективна информационна, технологична и организационна среда за показване и прилагане на процесния подход на предприятието. Тази среда, която, от една страна, позволява на всяко заинтересовано лице да "изрази" качествени и количествени предложения за подобряване на дейността на предприятието, а от друга страна, всички участници обективно да оценят "положителните" и "отрицателните" аспекти на предложението.

Освен че повишава „информираността“ на участниците в бизнес процесите за тяхната мисия в дейността на предприятието, „новата“ корпоративна култура осигурява задължителното документиране и запазване на историята на всички промени, свързани с целевата дейност на предприятието. предприятие. Такова педантично и качествено формализирано отношение към годините натрупани знания в организацията е в основата на тяхното ефективно използване.

Разширяването на заинтересованите участници в изграждането на модела и формирането на нова корпоративна управленска култура в по-голяма степен е условие и/или следствие от проекта за моделиране. Практическите стъпки за изпълнение на проекта се формират въз основа на разбирането на съдържанието на целевите задачи за моделиране.

Задачите за моделиране следват от целите, формулирани от организацията за подобряване на нейната дейност. Както беше отбелязано по-горе, целевите задачи за моделиране на бизнес процеси са разпределени в две основни области:

1) систематизация и формализация - изграждането на описателни модели;

2) изграждане на аналитични и оптимизационни модели.

В рамките на избраните области може да се извърши допълнително разделение на области, като се има предвид наличието на два основни вида изследвания, а именно самите бизнес процеси и ресурсите, участващи в бизнес процесите. Въз основа на това, такива подзадачи като:

1) качествена и количествена оценка (оптимизация) на реализираните бизнес процеси;

2) качествена и количествена оценка (оптимизация) на използването на ресурсите на организацията в рамките на текущите бизнес процеси.

Във връзка с бизнес процесите, задачите за моделиране могат да бъдат разделени на типове процеси: основни, позволяващи, външно взаимодействие и развитие (вижте Глава 2). По отношение на "непроцесните" обекти на изследване, задачите за моделиране могат да бъдат определени за процесите на формализиране на целите на предприятието, организационна структура, технологична структура, информационна структура, архитектура на бизнес функции, регулаторна рамка, ключови показателидейности и др.

Допълнителна систематизация на задачите за моделиране може да се свърже с внедрените методи за конструиране и използване на модел на бизнес архитектура на предприятието. Примери за такива задачи могат да бъдат: функционален анализ на разходите, симулационно моделиране, систематизиране и формализация.

На практика следните актуални въпроси са групирани според избраните области на поставяне на задачите за моделиране на бизнес процеси, на които ръководството на организацията би искало да получи аргументирани отговори:

♦ Какви са интегралните разходи и времеви разходи, необходими за прилагане на определен бизнес процес (подпроцес)?

♦ Какъв състав от организационни, технологични и информационни ресурси, както и регулации, са необходими за извършване на определен бизнес процес?

♦ Каква е динамиката на използване на организационни, технологични и информационни ресурси, необходими за осъществяване на определен бизнес процес?

♦ Какви ресурси (организационни, технологични и информационни) или регулации са основните ограничаващи фактори за разширяване на способността на организацията да повишава качествените и количествените характеристики на решаваните бизнес задачи?

♦ Какви операции (работни функции) са възложени на конкретно служебно звено в рамките на целевата дейност на организацията?

♦ Какъв списък от операции ( маршрутизиране) трябва да се извършва от служебното звено при възникване на конкретна стандартна или нестандартна ситуация, свързана с изпълнението на целевата дейност на организацията?

♦ Какви качествени и количествени подобрения трябва да се очакват след модернизацията (въвеждане на нови) информационни системи, нормативни актове, организационни единици, производствени технологии и др.

Горните насоки за поставяне на задачи формират група от условно наречени задачи за технологично проектиране на модела („архитектурни“ задачи). В същото време обективно съществува независима група от задачи, свързани с логиката на организиране на изпълнението на проект за моделиране:

♦ дефиниране на етапи;

♦ дефиниране на ролите в проекта;

♦ формиране и управление в проектния екип и др.

Този списък от задачи, както и изпълнението на "архитектурни" задачи, ще бъдат разгледани по-подробно в други раздели на книгата.

Трябва да се отбележи, че качественото формулиране на постановки на проблеми за моделиране на бизнес процеси във връзка с профила, текущото състояние и приоритета на проблемите на организацията е ключово условие за успеха на проекта. Трябва ясно да се разбере, че не само всички заинтересовани, но и компетентни лица трябва да участват в определянето на целите. При решаването на такива проблеми е необходимо да се изключат възможни ситуации на замяна на бизнес компетентност (на ниво правна, технологична, управленска) с ИТ компетентност и обратно.

Съвсем естествен и основателен въпрос, след като разберете кому и защо е нужен модел на бизнес архитектура, е да се изяснят параметрите и принципната възможност за изплащане на този вид консултантски проект.

Такава постановка на въпроса, както и формирането на отговор на него, не се различават много от ситуацията, когато се оказва защо е необходима концепцията за информационна система при иницииране на мащабни проекти за информатизация на организация.

Усилията за изграждане на бизнес архитектура, която е представена под формата на бизнес модели, бързо се изплащат и имат голям брой допълнителни придобивки. Ползите от изграждането на модел на бизнес архитектура от модели се крият в две равнини: допълнителни функциибизнес и намаляване на разходите. Смята се, че създаването на бизнес модели и свързаната с тях оптимизация на разходите, дори и без радикални промени в бизнеса, може да осигури до 10% спестявания. А при моделиране на алтернативни опции за бизнес процеси организациите могат да спестят до 20%.

Започнах да работя с една компания по темата за корпоративната архитектура (Enterprise Architecture) и реших да коригирам разбирането си за EA, за да го направя по-ясен и по-прост. Публикацията от 1987 г. на Джон А. Закман "Рамка за архитектура на информационни системи" обикновено се смята за рождена дата на EA, въпреки че самият термин се появява в по-ранни писания. Въпреки факта, че архитектурата на предприятието е доста млада, тя вече успя да развали репутацията си. Като всяка друга архитектура, корпоративната архитектура не е добре дефинирана (вижте например 10 дефиниции на корпоративна архитектура), но има голям брой неуспешни проекти (вижте Gartner идентифицира десет клопки на корпоративната архитектура или 8 причини, поради които програмите за корпоративна архитектура се провалят) . Обикновено след завършване на проект за корпоративна архитектура можете да чуете следната фраза: Начертали сме всички необходими картини, но нямаме идея как да извлечем поне някаква полза от това.". Затова нека поговорим за всичко от самото начало.

И ще започнем отдалече. Има две гледни точки относно полезността на информационните технологии. Според първата гледна точка Информационни технологииви позволяват да увеличите производителността на труда, т.е. хората ще работят по-ефективно, ако дейностите им са автоматизирани. Съществува и противоположна гледна точка, изразена например в книги като „Блясъкът и бедността на информационните технологии. Защо ИТ не е конкурентно предимство“ от Никълъс Дж. Кар или „Какво бизнесът иска от ИТ“ от Тери Уайт. Изненадващо и двете гледни точки са верни. Но нека стесним кръга на нашите разсъждения и нека говорим не за информационните технологии като цяло, а само за бизнес приложенията, т.е. системи, които автоматизират бизнес процесите на организацията. Първо, разработването и внедряването на такива системи носи осезаем ефект. Когато различни служители започнат да отразяват подобни операции в една база данни, достъпна през мрежата от различни работни места, взаимодействат помежду си чрез такива решения и се специализират в определени функции, тяхната производителност се увеличава. Това е много по-добре, отколкото да се обаждате по телефона или да си разменяте емоционално заредени съобщения електронна поща. Следователно започват да се автоматизират различни други процеси, може би не толкова чести и не толкова необходими. Ефективността на такава автоматизация не е толкова висока. Ниско висящите ябълки вече са откъснати и трябва да измисляме по-сложни начини за постигане на резултата. В един момент разходите за използване на бизнес приложения стават по-големи от ползите, получени от използването им, но вече не е възможно да се спре овърклокнатият локомотив. Причината за този праг е органичната сложност на информационните системи (IT Complexity). Всъщност в един момент просто се объркваме какво правим, а информационните системи ни помагат да се объркаме още повече. Архитектурата (предприятието) е просто начин за контролиране на сложността, присъща на системите, за поддържане на повече или по-малко адекватна картина, като същевременно позволява тази сложност да бъде управлявана.

Следващият проблем е, че такава картина не може да бъде подготвена за бъдещето. (В този момент архитектите ще ви кажат много модни думи за различни гледни точки, възгледи, заинтересовани страни и опасения). Следователно, за да отговорим на въпроса „Защо правим корпоративна архитектура?“ необходими от самото начало. Позволете ми да подчертая трите най-често срещани отговора:

1. Имаме стратегия, която отговаря на въпроса какво искаме, но не знаем как да го направим.
2. Нямаме стратегия, но имаме поток от заявки за промяна, с които не можем да се справим.
3. Информацията за нашата дейност е противоречива и нямаме време да разберем във всеки случай защо се случва това.

(Ако смятате, че има други, по-чести опции, моля, отбележете го в коментарите).

В първия случай трябва да направим Стратегии –> План. Става въпрос главно за бизнес стратегия. Обикновено изглежда като набор от някои разлики между това, което имате и това, което искате, изразено с доста прости думи: пазарен дял по отношение на приходи, клиентска база и т.н. Като цяло, нали знаете, стратегията е документ за утрешните таралежи , които ще станат днешните мишки. Ще напиша какво трябва да се направи в този случай в отделно съобщение, но засега няколко думи за това как да организираме такъв процес. Според мен организационната форма на разработване на корпоративна архитектура е проект с продължителност 8-16 седмици. Методология - TOGAF ADM и др. Трябва да се привличат ресурси, предимно вътрешни. Резултатите от проекта са: пътна карта, списък с организационни и процесни промени, рискове, предложения за мониторинг и управление на движението в дадена посока. Като цяло всичко, което се прави в традиционните проекти на етапа на планиране, се нарича красива дума основен план. За екипа на такъв проект, набор от дейности и артефакти - същото в някое от следващите съобщения.

Вариант номер 2: Управление на промените. Вместо стратегия има набор от различни цели за различните бизнес клиенти. Някои трябва да намалят разходите, други трябва да пуснат на пазара нови продукти и услуги, а трети трябва да подобрят удовлетвореността на клиентите (вижте накратко За корпоративната архитектура). Всички клиенти са уважавани хора и всеки има нужда от помощ. Но сложността вече е нараснала и не разбираме как да помогнем на всички едновременно. прости и Грешен начинпостави всички в съответствие с красиво име, например "Единен списък с приоритети", а методът за разпределение на задачите между информационните системи - "Безплатна каса!" - който може да го направи по-бързо и по-евтино, ще му се доверим. Правилното решение- многофакторна класификация на заявките, с други думи - таксономия. Методика - в стила на Захман. Организация - създаване на функционална единица. В предишна бележка бизнес анализаторите приятели ли са, съседи или далечни роднини? Написах, че с появата и приемането на третата версия на BABOK, бизнес анализаторите ще могат да вършат тази работа. Но засега не могат. В момента бизнес анализаторите могат да отговорят на въпроса „Какво трябва да се направи?“, А архитектите на решения могат да отговорят на въпроса „Как да го направя?“. Също така изисква отговор на въпроса „Защо?“, как тази промяна е свързана със съществуващи продукти и процеси, други промени, приложения.

И накрая, ситуацията, когато сложността вече е победила и лидерите на организацията са наясно с това. за същите Снимки, които не са там, когато са необходими за бързо решаване на спорен проблем, а през останалото време са напълно безполезен товар. Тази ситуация говори за архитектурно хранилище. Може някъде да има снимки, описващи архитектурата, но ако те не могат да бъдат получени в рамките на минута или две, тогава управителят и всеки управител няма да го направи сам, а ще помоли някой друг да вземе снимката („Обадете се на архитекта тук !"). Ако човек не работи с приложението поне веднъж на 1-2 седмици, значи няма да го прави изобщо. Ако разработчикът на информационната система няма прости, разбираеми и готови за използване API за получаване на типове клиенти, списък с клонове, функционална организационна структура и т.н., тогава той определено ще добави още една табела в своята информационна система , в който той ще принуди потребителите да въвеждат данни от тези директории отново. Не ми е известен нито един инструмент на EA, който да е еднакво подходящ за демонстриране на красиви снимки на топ мениджъри и в същото време да притежава вродена оперативна съвместимост за интегриране в реални бизнес приложения. Надявам се, че такива, рано или късно, ще се появят. И тогава вариант номер три ще се превърне в прост проект за внедряване на информационна система и нейното последващо използване и развитие.

Следва продължение (история за архитектурата на предприятието)!