Да поговорим за ИТ фирмите и обществените поръчки

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

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

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

• Некадърни фирми – да, ясно е, че има такива и то немалко – фирма с 1 старши разработчик и 7-8 младши за колкото може по-малки заплати, да наливат код, и все нещо ще излезе. Старшият разработчик ще следи процеса, и готово. Той самият може да не е достатъчно добър, но поне има опит. След това тези младши разработчици се изстрелват при първа по-адекватна възможност, защото виждат какъв ужас е. Има и други фирми – които си имат разработчици и мениджъри с опит, но просто никога не са правили софтуер както трябва. Винаги е било с процес „каубойско писане на код“, и „мазане“ – без оглед за производителност, информационна сигурност, удобство… и все някой друг е виновен. Някои не ползват контрол на версиите, не знаят какво е уеб-услуга и като цяло – останали са в 90-те. Виждал съм такива неща, че и за курсов проект не стават. В такива случаи администрацията може и да опита да минимизира щетите и все пак да изкара нещо от проекта, но това би било по-скоро късмет.
• „Окопани“ фирми – когато „гаражна“ фирма е направила някакъв софтуер преди 20 години, който е успяла с някакви връзки да пробута я на някоя община, я на някоя областна или централна администрация, и после само тя може да го надгражда или поддържа. Промяната така или иначе е трудна, но дори при опит от страна на администрацията да се смени софтуера, има тежък отпор, който понякога стига до това да не се дава базата данни за миграция към евентуална нова система или пък до абсурдни твърдения, че фирмата има авторско право върху информацията в базата данни. Такива примери има твърде много и те са сериозен фактор.
• Корупция – да, ясно е, че корупция има. И то доста. Някои фирми са „установени“ в някои администрации не просто заради предишен опит, ами и по линия на някакви политически връзки. Това го разбрах с почти челен сблъсък със системата на корупция – в една фирма, в която работех за кратко, едни шеф ме помоли да отида в едно министерство и да участвам в работна група по писане на задание. За поръчка, която явно е трябвало да спечелим. Трябваше ми около половин ден да загрея за какво точно става дума, но на въпроса „значи аз трябва да се правя на независим експерт и да напиша задание, по което после ние да кандидатстваме и да спечелим“ отговорът беше „Ами да. Те всички така правят“. Отказах да го направя (имайки лукса на гъвкавия и гладен софтуерен пазар), и в крайна сметка поръчката така и не се случи, но важното беше, че „всички така правят“. В случаите, когато фирмите не си пишат сами заданията, им ги пишат приятелски фирми, а след това се редуват. И после като резултатът е зле – „ами то така пишеше в заданието“. (Периодично има по някой скандал с това, че в метаданните на документите за някоя поръчка пише като автор – служител на някой от кандидатите). Противно на очакванията, обаче, не мисля, че ако махнем корупцията, всичко ще цъфне и върже. Останалите проблеми ще са налице и няма да позволят магическия прогрес (това не значи, че не трябва да се борим против нея, естествено). Корупцията има и друг аспект – фирми, които не са „в играта“ не кандидатстват, защото не знаят дали поръчката не е нагласена за някого. Нерядко стои въпросът „абе тая поръчка гласена ли е за някого или да участвам?“.
• Недостатъчен капацитет – някоя фирма може да е добра, но да се е надценила и е кандидатствала по повече поръчки, отколкото може да поеме, но пък е взела, че ги е спечелила, и сега се чуди как да ги изпълни. Приоритизира един, забавя друг, наема хора „от кол и въже“, колкото да спази сроковете.
• Остарели основни системи – когато основните ти системи са остарели и нямам как да направиш адекватна интеграция с тях, задачи, които са изглеждали лесни, стават доста трудни. Примери много, но да вземем МВР, където доскоро имаше стара система за регистрация в КАТ. На база на тази система нови функционалности, оптимизиране на процеси и други неща нямаше как да станат, или поне не лесно. Имаше един регистър, който е правен през 90-те. Доста неща зависеха от него, но просто нямаше как да се интегрират. И съответно интеграцията с него става „ръчно“. Примерите с носене на флашки рядко са заради липса на мрежда – по-често са заради стари системи без никакви точки за интеграция
• Лоши задания – дори когато сме извън сценария „изпълнителят сам си пише заданието“, заданията са лоши. Администрацията рядко има капацитет да напише адекватно задание. Или копира от стари задания, или възлага на някой консултант да го напише (който я разбере за какво е поръчката, я не…а и да разбере, предава нещо полу-грамотно, което после трябва да се пише от нулата). А резултатът зависи в немалка степен от заданието – фирмите, разбираемо, често си дават зор повече от това, което се изисква от тях (има и похвални изключения). И съответно могат да свършат и чудесна работа, и никаква работа – зависи какво им се търси. Именно заради проблема със заданията въведохме две мерки. Едната е шаблонно задание с всички настъпвани през годините „мотики“, така че да не се правят нещата грешно. Разбира се, шаблонът допуска редакции за конкретния случаи (напр. ако системата не предполага пълнотекстово търсене, такова няма нужда да се изисква), но като цяло ограничава полето за ТНТМ-та. Другата мярка беше Държавно предприятие „Единен системен оператор“, което да поеме писането на задания (както и други дейности по проектите). Второто така и не се е случило все още.
• Лошо управление на проектите от възложителя – това често е голям проблем. Може фирмата да има доброто желание и капацитета да направи проекта както трябва, но в администрацията просто няма никой, който да знае как се движи проект. Това беше още една причина, поради която въведохме Държавно предприятие, а също така и кратко преживял Project management office в Администрацията на Министерския сътвет. И двете в момента отсъстват и затова нещата се движат от редови служители в администрацията, които в добрия случаи са викали неволята достатъчно много пъти и горе-долу знаят как се управлява проект. В лошия (и вероятно по-масов) случай просто разписват протоколи и приемат проекта. Има десетки неща, за които възложителят има задължения – да осигури права за интеграция с други системи, да осигури хардуер (ако такъв не е заложен), да осигури помещения за хардуера (ако такъв е заложен), да осигури уточнения по изискванията на нормативната уредба в частта с бизнес анализа, и т.н. Има и друг тип проблеми – възложителят да има необмислени изисквания и да държи на тях, въпреки съветите на изпълнителя – напр. „това на уебсайта трябва да е точно както е на хартия“.
• Независещи от никого обстоятелства – често срещан пример е срокове по някой закон (или Регламент на ЕС), които администрацията е опитала да спази в срок, ама заради тромави процедури, обжалвания, събаряне на търгове, КЗК, ВАС (малко корупцийка, съответно), нещата не са се получили. И когато все пак се стигне до изпълнение на проект, сроковете вече са „за вчера“, обаче политическият натиск расте, и съответно резултатът се приема с едно затворено око и едно гледащо в другата посока.
• Липса на политическа подкрепа – един проект може да бъде неглижиран от политическото ръководство и това да го направи невъзможен за изпълнение. Например често се налага изменение на някоя наредба или заповед, за да може да се използват всички възможности на софтуера. Обаче ако никой от политическият кабинет „не даде едно рамо“, наредбата си остава от 94-та и програмистите псуват какви глупости ги карат да правят
• ЗОП – на последно място, но изобщо не по важност, Законът за обществените поръчки е неподходящ за софтуерни проекти. Прекалено е бюрократичен и предполага до голяма степен т.нар. waterfall модел, което предполага много ниска гъвкавост. Освен всичко друго, за кандидатстване по процедура по ЗОП, фирмата трябва да има хора, които могат да се оправят с бюрократичния процес (който с новата директива е малко по-добър, но все пак изисква познаване на процедурите и опит с писане на документи). Как да напишеш офертата и техническото предложение, така че да покрият критериите за оценка, как да се вместиш в сроковете за кандидатстване. Ако нямаш опит със ЗОП, т.е. ако предимно работиш за частни клиенти, например извън България, то едва ли имаш голям шанс в една процедура по ЗОП. Съответно пък по ЗОП не можеш да оцениш реално кандидатите – всичките имат сертификати, всичките имат годишен оборот и всички ще напишат в техническото си предложение, че ще изпълнят всичко. И особено ако администрацията не е достатъчно технически грамотна, няма да може да оцени кой е вникнал повече в заданието и е разписал по-адекватно предложение. Бях предложил преди време като част от документацията по кандидатстване, да се представя код от предходни проекти, на база на който да се извличат някакви метрики – качество на кода, покритие с тестове и др. Само че „по ЗОП не може“.

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

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

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

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

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