Изпълнението на проекти за интеграция рядко без затруднения. Обмисляме как да ги преодолеем
За да започнете, ние се отбележи, че целта на проекти за интеграция не е организация на данни между различни системи, както понякога се смята. Всъщност, трябва да се постигне оптимално автоматизация на бизнес процеси, в които искате да прехвърлите данните. И че концептуалните различия могат да доведат не само до увеличаване по отношение на проекта за интеграция. но също така и към общия неговия крах. Клиентът, мислейки, че задачите, преди да е местен, от само себе си, без проучването определя потоци за интеграция. и интегратора е да ги свърже, който не е свързан, специалисти на компанията. Но в подхода ", ето списък потоци - интегрира" има огромен риск: след могат да бъдат идентифицирани интеграцията на липсващите потоци, които блокират автоматизация на бизнес процесите. В тази статия ще опишем възможните проблеми, възникващи в хода на проекта, заедно с рецептите на техните решения.
Проблем номер 1. Аз не съм и не ми беше крава, или проблемите на взаимодействието
Интеграцията не винаги включва интегрирането на двете системи са често първоначално приема, често "сприятеляват" трябва да е от 3 до 5 системи. В този случай, 90% на риска от грешки поради забавянето на времето при хармонизиране на работата е необходимо. Все по-голям брой участници в проекта от страна на клиента, както и не всички от тях се разбере значението на взаимодействие с екипа на интеграция. отговорно за процеса и др.;
Проблем номер 2. «бавно и стабилно победи - на става" не винаги работи
Друг фактор, който с течение на времето може да бъде много "издуват" условията на проекта - в синхрон действия на всички свои членове, особено фирмите за прилагане. Например, системата, която искате да се "сприятеляват" с прилежащата приложението, за да започне работа по интеграция все още не е въвела и не е окончателно документирана от гледна точка на изискванията и процесите.
Интеграция поток - набор от данни, предадени от една система източник в приемника с помощта на автобус интерфейс интеграция. Като част от интеграцията тече няколко възможни взаимодействия между автобус източник система и приемника на системата.
Сложността се определя от поток атрибут предаваните данни за състава и броя на свързаните с тях разговори:
- Средната сложност - един изход услуга, не повече от 50 атрибути на данни;
- комплекс - 1-3 изход услуга, повече от 50 атрибути данни;
- повишена сложност - повече от 3 услуги изход.
Тези две общи проблеми за решаване. Трябва да се регистрирате поне регламент на взаимодействия, където последователността от действия на всички етапи на проекта са ясно дефинирани високо равнище, за да се подготвят изходните документи, съответстващи на броя на участниците и условията на бележки координация / доставка. Това ще намали риска от грешки и вероятността от по-нататъшни действия на факта, от коя страна на топката, кой е отговорен в случай на ирелевантност документи, описващи системните изисквания или слабо развити.
На следващо място, считаме, че "събирателен образ на" проекта интеграция в българска банка със средни размери, който се основава на нашия опит. Да предположим, че ние трябва да се "сприятеляват" с предно и бек-офис системи.
Проблем номер 3. пилета си, преди те да са се излюпили
Първоначално Банката "държави" в проекта около 3 дузина интеграция потоци. Основните процеси, които да бъдат автоматизирани, - създаване и поддържане на клиент, създаване на договора за кредит и последващата поддръжка на кредитополучателя.
След проучване на бизнес процесите на броя на нишки се увеличава с повече от половината. Те са "умножена", включително и поради факта, че системата за предна линия не се "помисли" на определен брой потоци от общите банкови продукти (договори за кредит, кредитна линия, и т.н.), както първоначално се очакваше. За нея, всеки един е подобен продукт, отделна нишка.
С 5 от тези банкови потоци - създаването на молба за кредит в задния офис, трансфер кандидатстване за кредит по договор за кредит и т.н. - са изключени от проекта, тъй като прилагането на бек-офис система не се съхранява в него веднага след като проектът бъде одобрен договорът за заем е създаден в предната система.
Без описание на бизнес процеси предварителен преглед и не точно, дори и ако банката е уверен, че "знае, която интегрира". Изследването определя Обхват интеграция потоци, идентифицирани тяхната последователност, приоритет на изпълнение може да бъде създадена необходимо финес системи.
Проблем № 4. Тили сварени системи тестото или несъвместимост
Дори и подробно описание на бизнес процесите не може да гарантира липсата на грешки в прилагането на логиката на интеграционните потоци. При определяне на потоците и техните атрибути могат да бъдат срещнати системи, свързани с несъвместимост по отношение на тяхната операционна логика. Ние се върнем към нашия пример за предно и бек-офис системата.
Като част от "създаването на договора за кредит", ние определяме 2 интеграция поток за създаването на допълнителен застрахователен договор: първият - за създаването на застрахователен договор, на 2-ри - я обвърже с договора за кредит. Съответно за тези потоци система изпълнява в предните две различни методи: 1-во - за да започнете да създавате договор в бек-офис система, на 2-ри - за свързването му с договор за заем.
Но се оказва, че бек-офис на работата на системата логика не позволява създаването на застрахователен договор, без едновременно определяне на договора за кредит, допълнително споразумение за кредит могат да се отнасят за общия застрахователен договор.
По този начин, на потока за създаване на договор за застраховка трябва да бъде един, и начина на създаването му трябва да включва "дърпа" на споразумението за заем данните, до които той се свързва. Ясно е, че съществуващата система на тактически методи за осъществяване на този поток няма да работи.
За да се определят ситуацията преди началото на развитието и да не се наруши графика на проекта, за всеки един от потока на интеграция, която искате да симулират поток от данни схема. Това ще разкрие алтернативните сценарии, с различно поведение на свързаните с тях системи, както и необходимите подобрения интегрируеми на бизнес приложения. За да се развие схеми на потоци от данни може да се използва UML диаграми нотация последователности.
Проблем номер 5. В счупен коритото?
По време на схемите за изследване и описание на всички потоци могат да се променят и изискванията на клиента в процеса на интеграция и на свързани системи. Не е изключено, че ние ще трябва да преразгледа обхвата потоци.
В този случай, трябва да се извърши съпоставка на всички, включително и тези, възникващи в хода на проекта, интегрирането на потоци и изискванията за завършвания в оригиналните тези бизнес процесите за идентифициране на евентуални пропуски и несъответствия. След тяхното отстраняване е възможно да промените приоритета на подобрения.
Проблем № 6. Бони и Клайд, или несъвместимост системи 2
Логично е, че напълно различни системи не могат да съответстват на характера и състава на атрибута. Така че, в нашия хипотетичен проект, когато създавате договор за заем изисква предаването на данни на отговорното лице, както и за привличане на клиенти по начини, които не се поддържат в системата на източника.
Ако гърнето не е единна система за централизирано поддържане на справочна информация (РПИ), ролята му често се разтвор интеграция.
Тези проблеми могат да бъдат открити само при определяне на структурите за предаване, техните видове и трансформации. Препоръчително е в ранните етапи на проекта, за да се развият пълните спецификации за всеки един от потока на интеграция за идентифициране на логиката и зависимостта атрибути отделно описват услугите, използвани в потоците за интеграция. След това информацията, която покрива необходимите атрибути са непълни и изисква по-нататъшно усъвършенстване на свързаните с тях системи, няма да бъде сериозна пречка за проекта.
Проблем номер 7. дело, един забавен час или планиран график
Така че, ние имаме пълно описание на бизнес процеси, спецификации всички потоци и много други много важна информация, че е време да насочи изпълнението на решение за интеграция. Но преди да започне да се развива, че е важно да не пропуснете всички промени, направени в първоначалния обхват.
Връщаме се към нашия проект: интеграция изпит бизнес процесите са идентифицирани 5 потоци, инициирана от бек-офис система. На първо място, в процеса на "създаване на договора за кредит", а останалата част - ". Услугата от страна на кредитополучателя" към Реализация поток поиска преразглеждане на бек офис приложения, така че това е установено, че по-висок приоритет в първия поток в началните етапи на проекта, отколкото други. След като описва спецификациите на всички 5 потоци стана ясно, че те имат обща структура и могат да бъдат приложени за единична услуга от страна на бек-офис. Това доведе до обединението на тези подобрения и повишаване на техния приоритет.
В допълнение към проблемите, свързани с липсата на снимката, не можем да забравим за интеграция решения тестване въпрос. Що се отнася до тестване, "вързани" всички участници в проекта, техните действия трябва да бъдат ясно синхронизирани.
За проекта отговаря на всички очаквания, че е необходимо да се извърши окончателна проверка на всички определени потоци, като се образува цялостна картина. Тя ще изготви графика за разработка и тестване. Необходимо е да се определи конкретната дата на прилагане на подобрения, дизайн потоци и тестване, както и всички заинтересовани страни. По-късно в плана, ще отбележат статуса на разработка и тестване.
Очевидно е, че могат да възникнат проблеми във всеки един етап на проекта за интеграция. Надяваме се, че сме описали "рецепти" на интеграция ще ви помогнат да ги избягвате.
Свързани статии