Модернизация на 12-годишна складова система, без да спираме камионите

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

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

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

Ситуацията: система, държана от паметта на един човек

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

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

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

Симптомите, които всички бяха престанали да забелязват

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

• Точността на наличностите се въртеше около 80%, така че персоналът ръчно проверяваше количествата на всичко важно — часове на ден, тихомълком.
• Логиката на списъците за комплектоване не можеше да се справи с настоящото разположение на склада, така че комплектаторите вървяха по маршрут, диктуван от папката, а не от екрана.
• Сверяването на наличностите в края на месеца отнемаше на двама души по-голямата част от три дни.
• Само една машина можеше да изпълнява административната част на софтуера, а ако тя се повредеше, никой нямаше ясен план.
• Нищо не беше свързано с онлайн канала за поръчки, който компанията беше добавила през 2019 г. — тези поръчки се препечатваха на ръка.

Какво съзнателно не направихме

Очевидният ход — този, който много доставчици биха предложили — е да купите голяма готова платформа за управление на склад, да мигрирате всичко за един уикенд и да изключите старата система в понеделник сутрин. Виждали сме този подход да се проваля достатъчно пъти, за да не го предлагаме за бизнес като този. Рязкото включване предполага, че разбирате старата система напълно. С едно десетилетие недокументирани заобиколни решения никой не я разбираше — дори хората, които я управляваха.

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

Затова не направихме нито едното. Третирахме старата система не като нещо за събаряне, а като нещо, което да обградим и бавно заменим — по една способност наведнъж, със старата система, която продължава да работи отдолу като предпазна мрежа през целия път. Без блясък. И същевременно единствената версия на това, която надеждно работи.

Подходът: удуши старата система, не я взривявай

Сред разработчиците има утвърдено име за този модел — подходът „удушвач“, кръстен на лиана, която расте около дърво, докато може да стои сама, а оригиналът тихо изчезва. Не заменяте старата система с един ход. Изграждате нови парчета около нея, насочвате реална работа към тях едно по едно и оставяте старата система да се свива, докато остатъкът стане достатъчно малък, за да го изключите, без никой да затаи дъх.

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

1. 1
   Картографирай какво реално прави системата

   Три седмици сянка след работата в склада и офиса, за да документираме реалния работен процес — включително всяка таблица и заобиколно решение от папката. Записахме системата, която съществуваше, а не тази, която описваше първоначалната спецификация.
2. 2
   Изчисти данните, преди да ги преместиш

   Направихме пълно физическо преброяване на наличностите и почистихме продуктовата база спрямо него. Мигрирането на мръсни данни в нова система просто ти дава по-бърз грешен отговор — затова това стана преди какъвто и да е нов софтуер да докосне данните.
3. 3
   Замени първо най-болезненото парче

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

   След това свързахме онлайн канала за поръчки директно с новите данни за наличности, премахвайки ръчното препечатване, което тихо съществуваше от 2019 г.
5. 5
   Отлюспи останалото, после изведи стария център от употреба

   Комплектоването, отчетите и сверяването преминаха едно по едно. Когато почти нищо реално не работеше на старата система, най-накрая я изключихме — вече несъбитие.

Частите, които наистина бяха трудни

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

Недокументираното правило, което счупи функция

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

Спечелване на доверието на склада

Складовият персонал беше преживял повече от едно благонамерено „подобрение“, което беше влошило деня им, така че посрещна проекта с основателно подозрение. Не се борихме с това с презентация. Избрахме комплектатора, който се оплакваше най-силно, седнахме с него за една сутрин и преизградихме екрана за комплектоване около това как той реално обхождаше склада. Щом той започна да защитава новата система в стаята за почивка, останалите последваха. При проектите с наследени системи най-острият критик, веднъж спечелен, става твоят най-добър застъпник — а това не можеш да го купиш със служебна записка.

Резултатите, една година по-късно

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

Числото, което най-много вълнуваше собственика, не беше в нито една диаграма. Беше това, че когато оперативният мениджър наистина се пенсионира — няколко месеца преди срока, както се оказа — складът дори не се олюля. Знанието, което някога живееше в нейната глава, сега живееше в система, на която всеки можеше да бъде обучен за дни. Първоначалната причина за целия проект беше тихо и напълно решена.

Ако седите върху система като тази

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

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

Често задавани въпроси