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

В един скорошен разговор клиент каза: „Ние ще се научим да работим спрямо софтуера.“

Отговорът беше: „Софтуерът трябва да се научи да работи спрямо бизнеса.“

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

За да стане това, екипът по разработката трябва първо да разбере защо компанията работи по този начин.

Първият въпрос е каква е целта на системата

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

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

В Sirius Software началните въпроси са свързани с целта: как работи компанията в момента, къде се губи време и какво трябва да стане по-лесно след внедряването.

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

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

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

Отвън трудно се вижда кои детайли са важни

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

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

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

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

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

И двете гледни точки са необходими.

Логичната функционалност невинаги е полезна

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

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

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

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

Затова всяка по-съществена идея заслужава няколко въпроса:

  • Кой конкретно ще използва тази функционалност?
  • В кой момент от работата му е необходима?
  • Какво прави този човек сега и какво ще се промени?
  • Как ще разберем дали промяната помага?

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

Софтуерът трябва да се съобразява с ефективните процеси

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

Репликата „ще се научим да работим спрямо софтуера“ звучи съвсем естествено. Всяка нова система изисква известно обучение и промяна в навиците.

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

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

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

Персонализираният софтуер има стойност, когато запазва силните страни на бизнеса и премахва конкретни затруднения в работата му.

Разбирането на бизнеса включва и професионално несъгласие

Работата по една система включва и преценка дали поисканото решение е подходящо. Особено когато засяга сигурността.

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

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

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

Качеството се вижда и след първите месеци

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

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

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

Тук разбирането на бизнеса отново има значение. Когато са ясни основните процеси, зависимостите и посоката на развитие, техническите решения могат да ги отчитат.

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

Как да започне разговорът за вашата система

За първия разговор с екип по разработка е полезно да подготвите един реален процес от началото до края. Включете хората, които извършват ежедневната работа, и опишете:

  • Как постъпва задачата и кога се счита за приключена.
  • През кои хора и системи преминава.
  • Къде се губи време и какви изключения възникват.
  • Какво работи добре и трябва да се запази.
  • Какъв резултат очаквате от промяната.

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

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

Ако обмисляте разработка на персонализиран софтуер, изпратете запитване до Sirius Software. Опишете как работите в момента, къде срещате затруднения и какъв резултат очаквате. Това дава добра отправна точка, за да определим какво си струва да бъде разработено и с какво да започнем.

За автора: Георги Папучаров е съосновател на Sirius Software (Сириус Софтуер) и работи по персонализирани бизнес системи и интеграции. Статията отразява неговия практически опит и принципи при работа с клиенти. Сценариите с поръчки, справки и права за достъп са илюстративни.