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

Защо тази тема е важна днес

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

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

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

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

Къде най-често нарастват разходите или рискът

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

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

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

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

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

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

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

Най-много проблеми възникват на границата между управлението и специализирания софтуер. Типичен пример е приложение, което променя начина за избор на рецепти, задава параметрите на работната последователност или влияе върху правата на оператора. За software house това може да изглежда като обикновена функционална промяна, но за интегратора и поддръжката на производството това е намеса в поведението на системата, диагностиката и процедурите по пренастройване. Ако преди внедряването не е уточнено къде свършва отговорността за интерфейса и къде започва отговорността за логиката на процеса, корекция, направена „в производството“, може да наложи повторни изпитвания, актуализиране на инструкциите, а понякога и преработване на сервизните процедури. Именно тук темата преминава и в областта на бюджета: разходът за специализиран софтуер за индустрията не произтича само от писането на код, а и от това колко отговорност проектът прехвърля към етапа на валидиране, документиране и последваща поддръжка.

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

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

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

За какво да се внимава при внедряването

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

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

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

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