Да изградите, да конфигурирате или да купите: как решава един комитет с ясни критерии

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

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

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

Трите пътя, с думите на комитета

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

Да конфигурирате онова, което вече имате. Вашият ERP, Вашият CRM, Вашата платформа за работни потоци или Вашата основна система вече носят възможности, които може би не се използват или се използват наполовина. Конфигурирането е нагласяне на параметри, правила, формуляри и справки в рамките на онова, което производителят поддържа. Не се пише нов код или се пише съвсем малко и системата остава тази на производителя.

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

Да изградите по поръчка. Разработва се система за конкретния процес на компанията. Има собствен код, собствени решения и, ако договорът е добре направен, собствена собственост. Има и собствена отговорност за онова, което е изградено: някой трябва да го поддържа, тества и променя.

Има и четвърти път, който е добре да се спомене, за да не се промъкне без име: комбинирането. Често правилният отговор е продукт за частта, която прилича на тази на други компании, и част по поръчка за частта, която отличава Вашата. Трите пътя не се изключват взаимно; променя се мястото, където се прекарва линията.

Шест критерия за решаване

1. Колко отличава процесът Ви

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

Полезен тест за комитета: би ли могъл конкурент утре да купи същия продукт и да работи като нас? Ако отговорът е да, вероятно не си струва да се изгражда. Ако отговорът е не и тази разлика е именно онова, което искаме да защитим или да мащабираме, тогава изграждането, или поне изграждането на частта, която отличава, заслужава място на масата.

Тестът има обратна страна, която се забравя: не всичко, което компанията смята, че я отличава, наистина я отличава. Често «уникалното» е навик, натрупван с години, не предимство. Преди да платите за възпроизвеждане на един навик, добре е да се запитате дали клиентът би забелязал отсъствието му.

2. Колко е спешно и какво струва чакането

Продукт, който вече съществува, може да започне да работи за по-малко време от такъв, който тепърва ще се проектира, но «по-малко време» не е «малко време»: трябва да се конфигурира, да се прехвърлят данни, да се обучат хора и да се свърже. Конфигурирането в рамките на онова, което вече имате, обикновено е най-бързото от трите. Разработката по поръчка е най-често онази, която най-късно дава първия резултат, освен ако не се предава на части и първата част не е полезна сама по себе си.

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

3. Колко интеграция изисква

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

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

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

4. Кой ще го поддържа

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

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

5. Обща цена, не входна цена

Най-честото сравнение в комитета е между цената на продукта и бюджета на разработката. То е непълно. За да се реши, цената трябва да се гледа на няколко години и с всичките ѝ редове:

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

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

6. Излизането от доставчика

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

При продукта зависимостта е от производителя: от цената му, от календара на версиите му и от трайността му. Въпросът е какво става с данните и правилата Ви, ако утре поискате да смените продукта: могат ли да се изнесат, в какъв формат, с каква документация?

При конфигурацията зависимостта е двойна: от производителя на платформата и от онзи, който е направил настройките. Бизнес правилата остават вътре в инструмента; ако не са документирани извън него, трудно се възпроизвеждат.

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

Таблицата, която да занесете на комитета

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

Две бележки как да се използва. Първо: не броете колко клетки «са във ваша полза» при всяка колона; критериите не тежат еднакво за всички компании. Комитет с регулаторна спешност може да даде на втория критерий тежест, която друг комитет не би дал. Второ: таблицата служи най-вече за откриване на несъгласия. Ако двама членове на комитета оценяват различно една клетка, там е разговорът, който си струва да се проведе, преди да се наеме когото и да било.

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

Какво да попитате, преди да подпишете разработка по поръчка

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

Чий е кодът

Въпросът изглежда очевиден и е онзи, който поражда най-много недоразумения. Който плаща за една система, обикновено приема за даденост, че е негова. Ley Federal del Derecho de Autor (Федералният закон за авторското право) установява конкретни правила и е добре да се познават. Онова, което следва, е прочит на действащия му текст на сайта на Cámara de Diputados (Камарата на депутатите); не замества мнението на правния Ви отдел.

• Компютърните програми се защитават при същите условия като литературните произведения, както като изходен код, така и като обектен код (чл. 102).
• Всяко прехвърляне на имуществени права е възмездно и временно, а договорите, с които се прехвърлят, както и лицензите за ползване, трябва да се сключват писмено; в противен случай законът ги обявява за нищожни по право (чл. 30).
• Член 33 предвижда срок от пет години, когато прехвърлянето не го определя; за компютърните програми член 103 изрично изключва това ограничение. Формулировката на прехвърлянето и обхватът му трябва да се прегледат с правния Ви отдел.
• При произведение по поръчка член 83 установява, освен при договорка в обратния смисъл, правило в полза на този, който го възлага. За да се счита едно произведение за създадено по поръчка, член 83 bis изисква условията на договора да са ясни и точни, а при съмнение надделява тълкуването, по-благоприятно за автора.
• Имуществените права върху програма, създадена от служители при изпълнение на функциите им, принадлежат, освен при договорка в обратния смисъл, на работодателя (чл. 103, първа алинея). Ако онези, които разработват програмата, са служители на Вашия доставчик и действат в рамките на функциите си, тези права възникват у Вашия доставчик; ако участват подизпълнители или независими изпълнители, добре е веригата на собствеността да се провери писмено. Онова, което стига до Вас, стига според това, което казва договорът.

Практическият извод не е, че законът Ви отнема кода; той е, че собствеността е добре да се остави писмено, с изрични думи. Въпроси за договора:

1. Кой е титулярът на имуществените права върху предадената система и нейната документация и написано ли е?
2. Прехвърлянето е цесия на права или лиценз за ползване, изключителен или неизключителен? Те са различни неща, с различни последици.
3. Какво става с инструментите, библиотеките и компонентите на самия доставчик, които се използват повторно във Вашия проект? Често доставчикът запазва своите и Ви предоставя лиценз за ползване; тогава е добре да се знае дали този лиценз е безсрочен, прехвърляем и позволява ли на друг екип да поддържа системата.
4. Има ли срок, територия и условия на прехвърлянето и вписани ли са там, където законът го предвижда, за да имат действие спрямо трети лица (чл. 32)? Това е въпрос към Вашия адвокат, не общо твърдение.

Лицензи на трети страни

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

Въпроси за договора:

1. Съществува ли списък на всички компоненти на трети страни, с техния лиценз и версия? Поискайте го като предаваем резултат.
2. Ограничава ли някой лиценз как можете да експлоатирате, променяте или разпространявате системата?
3. Кои компоненти имат повтарящ се разход (абонаменти, услуги в облака, ключове) и на чие име са сключени? Ако са на името на доставчика, в деня, в който отношенията приключат, системата може да спре да работи.
4. Кой отговаря, ако даден компонент престане да получава поддръжка или в него се появи пробив в сигурността?

Критерии за приемане

«Предаването на системата» не е дата, а условие. Ако условието не е записано, предаването се договаря накрая, когато бюджетът е изразходван и натискът е най-голям, а страната, която най-много губи, е онази с най-малко възможност да изчака.

Въпроси за договора:

1. Какво трябва да може системата, за да бъде приета, изразено в ситуации, които можете да наблюдавате и повтаряте? «Да работи добре» не е критерий; «заявка с тези характеристики да се одобрява по този път и да остава записана с кой, кога и защо» е.
2. Кой изпълнява тестовете за приемане, в каква среда и с какви данни? Добре е да участва някой, който не е изграждал системата.
3. Какво става с дефектите, открити след приемането, и за колко време доставчикът ги поправя без заплащане?
4. Предават ли се автоматични тестове заедно с кода? Те позволяват системата да се променя по-късно, без да се залага на късмета.
5. Свързани ли са плащанията с предадени и приети части, а не само с изтичането на времето?

Предаване

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

Въпроси за договора:

1. Какво се предава освен програмата: изходен код във Вашето хранилище, документация как е сглобена и как се инсталира, указания за експлоатация и за възстановяване след повреда?
2. Кой ще приеме предаването от Ваша страна, определен ли е и има ли време за това? Предаване на «ИТ екипа» без имена обикновено остава в една презентация.
3. Може ли системата да се изгради наново от нулата от предаденото и проверил ли го е някой извън доставчика? Това е един от най-показателните тестове дали е имало истинско предаване.
4. Каква поддръжка има през един следващ период и при какви условия, и какво става, ако предпочетете да я поддържа друг екип?

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

Защо толкова много системи по поръчка завършват със спасяване

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

Първа причина: размерът и продължителността вдигат риска по-бързо, отколкото се предполага. Има емпирични данни за това. Bent Flyvbjerg и Alexander Budzier анализират 1471 ИТ проекта и установяват, че средното превишаване на разходите е около 27 %; но тази средна стойност крие опашка: около един на всеки шест проекта има превишаване на разходите от средно 200 % и забавяне от почти 70 % [1]. По-късно проучване, с извадка от 5392 ИТ проекта, установява, че превишаванията на разходите следват степенно разпределение: много проекти с малки отклонения и опашка от проекти с екстремни отклонения, така че ИТ проектите са «много по-рискови по отношение на разходите, отколкото обикновено допускат онези, които вземат решенията» [2]. Авторите предлагат като възможно обяснение взаимозависимостта между компонентите: проблем в един може да предизвика реакции в други [2].

Какво означава за комитета: правилният въпрос не е «колко ще се отклони средно», а «какво става, ако попаднем в опашката». Бюджет, който издържа само средния случай, не е предпазлив бюджет. Тези цифри са с висока достоверност по отношение на произхода си (проверени в източника), но описват извадки от ИТ проекти по принцип, а не само разработки по поръчка; не бива да се четат като вероятността Вашият проект да се провали.

Втора причина: неуспехът се измерва лошо и се цитира още по-лошо. В продажбените презентации често се виждат проценти на неуспех на софтуерни проекти, приписвани на доклада CHAOS на Standish Group. Добре е да се знае, че тези цифри са оспорени методологично. Eveleens и Verhoef в IEEE Software (2010) твърдят, че определенията за успех на Standish се основават единствено на точността на оценката на разходите, времето и функционалността; че тази мярка е едностранна и надува процентите на «неуспешни» проекти; и че осредняването на цифри, произведени от различни процеси на оценяване, всеки със свое неизвестно отклонение, лишава резултатите от значение. Като прилагат тези определения към собствените си данни (5457 прогнози от 1211 реални проекта), заключават, че цифрите на Standish не отразяват реалността на проучените случаи [3]. Затова тази статия не цитира проценти от CHAOS като данни. Ако някой Ви ги представи в предложение, попитайте за източника и за определението за неуспех, което ползва. Уговорката важи в двете посоки: няма основание и да се твърди, че всички проекти минават добре.

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

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

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

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

Шеста причина: няма критерий за излизане. Никоя система не е завинаги. Ако договорът не е предвидил как се извличат данните и правилата, заместването ѝ е още един проект с висок риск. Система, която не може да бъде изоставена, накрая се запазва по инерция, което я превръща в бавна версия на спасяване.

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

Как да го занесете на комитета: един лист, пет въпроса

За да не остане този разговор общ, предлагаме лист от една страница, който всеки комитет може да състави за един следобед:

1. Какъв процес е и колко го отличава? С теста на конкурента, който би могъл да купи същия продукт.
2. Колко струва чакането? В пари или в риск, на месец.
3. С кои системи се свързва и през какъв интерфейс? Списък, не едно изречение.
4. Кой ще го поддържа след три години? С име или с профил и с неговата документация.
5. Как излизаме? Какво взимате със себе си, в какъв формат и на чие име остава.

Ако комитетът не може да отговори на някой от петте, тази дупка е първият предаваем резултат, преди каквото и да е предложение. А ако няколко отговора са «не знаем», вероятно не липсва доставчик: липсва информация, за да се реши.

Какво прави Hábil

Hábil помага на организации да подредят това решение, преди да се обвържат с даден път: какво е добре да се конфигурира, какво е добре да се реши с продукт и какво наистина си струва да се изгради. Това е идеята на страницата Разработка по поръчка, където се обяснява как се договаря обхватът, какво се предава и на чие име остава.

Ако част от онова, от което се нуждаете, прилича на онова, което правят други компании, прегледайте обхвата, условията и приложимите интеграции на нашите продукти: Retícula, Pauta и Cuadre. Каквото покрива някой от тях, се конфигурира, вместо да се програмира, и проектът по поръчка може да се съсредоточи върху онова, което наистина е само Ваше.

Ако комитетът Ви вече е определил процеса, интеграциите и критериите за излизане, можете да съпоставите случая си с Hábil в първи разговор, безплатно. Пишете ни в WhatsApp, за да го поискате.