Во првиот дел од серијата дискутиравме како можеме да станеме нездраво зависни од нашиот добавувач и, пред сè, какви проблеми може да предизвика тоа за нашата компанија.
Денес ќе разгледаме што можеме да направиме за да избегнеме таква зависност.
1. Задржување на сопственоста врз процесот и системот, знаењето и плановите за нивниот развој
Ако одлучите дека не сакате да се грижите за ИТ и му давате општи упатства на вашиот ИТ добавувач, сте на најдобриот пат кон зависност. Она што може да ве изненади е тоа што овој пристап често предизвикува проблеми за самиот добавувач; бидејќи по некое време; барањата на клиентот почнуваат да се преклопуваат и да се испреплетуваат; а исполнувањето на новите барања станува голем проблем за добавувачот.
За компанија која сака да остане конкурентна, важно е да ја гледа ИТ како алатка за поддршка, подобрување и мерење на нејзините процеси. Не е тешко да се сфати како да се направи ова, бидејќи денес имаме доволно методологии и стандарди кои ни овозможуваат да одржуваме преглед на процесите и да спроведуваме ефикасно планирање:
- Претпријатиска архитектура – начин за опишување на целите на организацијата; начините на кои овие цели се постигнуваат преку деловните процеси; и како овие процеси можат да бидат поддржани од технологијата. За повеќе информации, видете ја статијата „Немојте да се заглавувате“ од лошата претпријатиска архитектура. Двата најпознати пристапи кон претпријатиската архитектура може да се најдат на веб-страниците на The Open Group и Zachmann .
- Опис на процеси – најпознатите и најшироко користените стандарди се создадени од Open Management Group (www.omg.org). Описот на процесите според спецификацијата BPMN (Business Process Model and Notation) им овозможува на менаџментот на компанијата лесно да ги чита и евидентира процесите што се одвиваат во нивната компанија.
- Документација за корисникот – ова не мора да биде документ напишан од добавувачот и ставен во фиока за да собере прашина. Добар пристап е да се снимаат видеа што им покажуваат на корисниците како да ја користат апликацијата во нивната секојдневна работа; со што се поедноставува поддршката за производот и обуката за новите корисници. Видеата често траат само неколку минути и опишуваат сè што треба да знаете за ефикасно да го користите системот. На пример; погледнете го упатството за користење на Yammer во истражувачки проект ; или упатството како да нарачате стока од онлајн продавница .
Сите стандарди и методологии се придружени со сеопфатна документација и материјали за учење кои детално ја опишуваат секоја област. Според моето искуство, вреди да се ангажира специјалист кој ќе ги избере деловите од методологијата што се соодветни за одредена компанија.
Ако го обработите вашето знаење во стандардизирана форма, не само што ќе имате алатка за дискутирање на теми што водат до подобрување на компанијата, туку ќе стекнете и сигурност дека ќе најдете заедничка основа со огромното мнозинство од вашите тековни и потенцијални добавувачи.
Ако сакате да промените нешто во вашите процеси и проток на информации; започнете со правење промени во организацијата на работата; или на ниво на модел или преку пилот-експеримент - тестирајте дали промената ќе ги донесе придобивките што ги очекувате. Потоа пресметајте ги придобивките од промената и трошоците за нејзино спроведување. Ако сè е како што треба; започнете со модифицирање на системите; а ако не; можете да ја запрете акцијата без никакви проблеми. Кога ова целосно ќе му го доверите на надворешен добавувач; малкумина имаат храброст да запрат проект во кој веќе сме инвестирале ресурси.
2. Податоците мора да бидат ваши под сите околности
Податоците се чуваат кај нашиот добавувач; сега се скаравме со нив и ни кажаа дека податоците се нивни... За жал, оваа ситуација не е толку необична како што можеби мислите. Не се случува често со добавувачите на услуги во облак и хостинг; како што луѓето честопати претпоставуваат; но најчесто со системи развиени по нарачка; каде што податоците се чуваат во црна кутија целосно контролирана од добавувачот.
Ова е традиционален начин клиентот да се држи под контрола на добавувачот. Проблемот генерално може да се реши на два начина – со директно контролирање на податоците или со обезбедување сигурен начин за нивно добивање во употреблив формат.
На пример; услуга за управување со контакти преку е-пошта што ги добиваме со регистрација на веб-страницата на нашиот добавувач. Првиот пристап е да се осигураме дека податоците се реплицираат во нашите сопствени системи; а вториот е редовно да ги преземаме информациите складирани во системите на добавувачот и да ги чуваме кај нас „за секој случај“.
Дури и во нашиот сопствен систем; каде што складирањето на податоци е добро документирано; методологијата на извоз на податоци во стандардна табела; база на податоци или XML може во голема мера да ја олесни интеграцијата на нов систем. Важно е да се воспостават процедури за извлекување на податоци; проверка дека извозот е функционален; и дека форматот е добро документиран; бидејќи критичниот момент кога треба да ги преземеме податоците е токму најлошиот момент да откриеме дека извозот не работи или дека совршено извезените податоци се кодирани во формат со кој не можеме да работиме.
Горенаведените барања треба да се проверат при прифаќање на каква било нова функционалност или промени во системите од добавувачот.
3. Задржете ги правата на интелектуална сопственост врз апликациите
Сопственоста на апликациите се состои од сопственост на изворниот код или дизајнот на апликацијата. Доколку немаме контрола врз изворниот код, ризикуваме кога ќе сакаме да ги смениме добавувачите, да откриеме дека постојниот добавувач поседува критичен дел од кодот и нема да биде подготвен да го обезбеди бесплатно. Можеме да го избегнеме ова со јасно дефинирање на сопственоста во договорот; наведувајќи дека кодот развиен како резултат на бараните промени е исклучиво наша сопственост; или дека овие промени се создадени под лиценца што ни овозможува да ги користиме и дистрибуираме бесплатно.
Дури и ако имаме договорно обезбедено сопственост; тоа не значи дека добавувачот со кого ќе го раскинеме договорот ќе ни даде пристап до кодот. Поради оваа причина, препорачливо е системот за контрола на изворниот код, вики-документите и другите документи да се чуваат кај трета страна и партнерот да биде обврзан да ги чува податоците на одредено место и во одредено време, за да имаме пристап до тековните верзии.
4. Системска интеграција наместо проширување на функционалноста
API-јата за веб-сервиси (интерфејси за програмирање на апликации) сега се вообичаена карактеристика кај многу комерцијални апликации и апликации со отворен код. Ова значи дека сите карактеристики или функции достапни за корисниците на апликациите се достапни и за употреба помеѓу различни системи и апликации.
Со користење на протоколи и стандарди за дефинирање на овој интерфејс; овие услуги се унифицирано средство за комуникација и платформа; апликација напишана на еден јазик или на еден оперативен систем е достапна за системи напишани на сосема поинаков начин. Податоците се пренесуваат во заеднички формат; како што се XML или JSON; а кодните бази на двата система остануваат целосно независни.
Денес, секој корисник може да замисли како изгледа системската интеграција. Впрочем, сите користиме услуги за веб-апликации кои се интегрирани едни со други - на пример; Google Calendar со Google Contacts и Gmail. Ако одлучиме да почнеме да користиме различен календар наместо постоечкиот, само треба да го поврземе со постоечките податоци. Овој метод на промена на системите не е можен ако имаме сопствен систем; кој првично го купивме само за сметководство, а постепено добавувачот разви CRM модул; модул за услуги; итн.
Истата логика важи и за интеграција со системи обезбедени како услуга од даватели на услуги во облак (SaaS – Софтвер како услуга). Употребата на веб-услуги ги одделува поединечните апликации една од друга; правејќи го целиот систем пофлексибилен и потранспарентен. Напротив, фиксните врски помеѓу различните модули му олеснуваат на добавувачот да ја зголеми нашата зависност од нив; ја зголемуваат комплексноста на кодот; а флексибилноста на системот е еднаква на најмалку флексибилниот дел.
5. Обидете се да ги минимизирате модификациите на стандардниот систем
Обидете се да го имплементирате потребниот систем со минимум модификации на стандардната имплементација. Обично не сте првиот клиент на добавувачот. Обидете се да го искористите максимално искуството на добавувачот со други клиенти за време на имплементацијата. Веројатно ќе бидете изненадени колку поефикасно можат да се имплементираат некои процеси или дека одредени податоци што претходно сме ги занемариле ќе станат наша конкурентска предност.
Доколку ни се потребни големи промени во функционалноста на апликацијата, ова може значително да го комплицира преминот кон нови верзии во иднина, а секоја транзиција ќе биде предизвикувачка во однос на развојот и имплементацијата.
6. Користете повеќе добавувачи
Обидете се сами да го управувате целиот дизајн, развој, распоредување и работење на системот и не го оставајте тоа на добавувачот. Добра идеја е да ги одделите бизнис аналитичарите од програмерите; на пример. Добра идеја е системот да го тестираат тестери кои се надвор од тимот за развој. Тие ќе ја завршат работата поефикасно; а веројатноста да добиете беспрекорен производ е многу поголема. Ако друга страна е одговорна за работењето (на пр., давател на услуги во облак); бидете сигурни дека тие ќе ги поттикнат програмерите да испорачаат производ што ги минимизира проблемите со работењето на системот.
7. Наведете го процесот на раскинување во договорот; вклучувајќи ги и казнените мерки за добавувачот
Како е наведено прекинувањето на соработката во договорот? Тримесечно известување; по што престанувате да плаќате, а добавувачот престанува да обезбедува поддршка? Тоа е жално несоодветно.
Потребно е да се наведе каква документација и со каков квалитет добавувачот мора да ви ја обезбеди; или директно до новиот добавувач; во текот на периодот на известување. Доколку сте обезбедиле права на интелектуална сопственост врз дизајнот; изворниот код и другите делови од документацијата споменати во точка 3; толку подобро. При склучување договор со добавувач, добра идеја е да проверите кај компаниите кои се на второ и трето место што ќе им биде потребно доколку сакаат да го преземат развојот и одржувањето од победникот.
8. Информирајте ги добавувачите за идните планови за развој
Работете на долгорочно партнерство со вашите добавувачи. Ако редовно ги дискутирате вашите планови за развој и стратешките прашања со нив; а не само тековните промени во функционалноста; добавувачот може да излезе со предлози што ќе создадат системска архитектура што е стабилна; ефикасна и исплатлива; не само за вашите тековни барања; туку и за идните барања. За да ги разјасните вашите барања, можете да го користите, на пример; методот MuSCoW; кој ги дели барањата во следниве категории:
- Мора да се има – мора да се има
- Требаше да има - требаше да има
- Можев да го имам – би било убаво да го имам
- Нема да имам овој пат – нема потреба да имам во овој момент
9. Добијте идеи и мислења од други страни
Не заглавувајте се на едно место; следете ги трендовите; барајте ги најдобрите пристапи и практики; и следете сè. Ангажирајте компанија за да добиете трето мислење - тие ќе ги оценат вашите одлуки и од техничка и од стратешка перспектива. Не мора да биде скапо. А таквите консултации се исплатливи бидејќи ќе ви помогнат да избегнете грешки. Од мое искуство; знам за случај каде што добавувач принудил клиент да инвестира неколку милиони круни во решавање на проблем што самиот го предизвикал; а консултант открил дека инвестицијата воопшто нема да го реши проблемот бидејќи проблемот лежи на друго место.
Консултантот може да ви помогне да ја дефинирате вашата стратегија; да создадете побарувачка; да ги оцените опциите; и да ги погледнете работите од неочекуван агол. Тие исто така можат да ви помогнат да ги ревидирате вашите добавувачи и да го обезбедите најдобриот можен резултат за вас. Консултантот секогаш треба да има предвид дека сакате да бидете независни од одреден добавувач и дека ја препознавате вредноста на вашето знаење како конкурентска предност.
Правилниот избор на добавувачи е поврзан со управување со ризик
Верувам дека откако ќе го прочитате овој напис, имате појасна претстава за тоа како да ги претворите вашите добавувачи во партнери во вашиот успех, а не да станете нивни вазали. Спречувањето на непријатните ситуации е поврзано со доследно управување со ризици и избор на решенија што ги балансираат тековните барања со идната флексибилност. Со почитување на горенаведените принципи, ќе го обезбедите правилниот избор на добавувачи и нови системи.
