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

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

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

Шест ситуации, които сочат към софтуер по поръчка

1. Редом със софтуера работи „сенчеста“ система. Използвате готов продукт, но същинското проследяване още се води в таблица или в имейл верига. Това е най-ясният показател, че продуктът не покрива реалния ход на работата.
2. Правилата за одобрение и възлагане са специфични за вас. Потокът на заявката, одобрението, възлагането, срока и статуса се променя според сумата, звеното или вида клиент и не се побира в готовите потоци.
3. Всяка роля трябва да вижда различен екран. Нужни са отделни права и отделен изглед за клиента, теренния екип, управителя и одитора; ролевата структура на продукта не го покрива.
4. Обменът на данни с други системи е задължителен. Данните трябва редовно да комуникират с ERP, счетоводство или външна услуга, а готовите връзки не го обхващат.
5. Ръководството иска други показатели. Нужните ролеви KPI, отчети и оперативна видимост надхвърлят стандартните отчети на продукта.
6. Операциите са интензивни и се повтарят. За екип, който върши една и съща операция стотици пъти на ден, всяко излишно кликване е голяма загуба; тези екипи се нуждаят от ефективен интерфейс за управление.

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

Готовият продукт все още може да е по-правилен

Софтуерът по поръчка не е отговор на всеки проблем. В следните случаи продължаването с готов продукт най-често е по-разумно:

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

Софтуерът по поръчка не е доставка, а продукт, който предприятието трябва да припознае; в деня на пускането на живо той не приключва, а започва да учи.

Реалните рискове на софтуера по поръчка

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

Как протича софтуерът по поръчка?

При софтуера по поръчка първо се проектира процесът, а не екранът, първо потребителят, данните и архитектурата на бизнес правилата, а не списъкът с функции. В проектите си за Софтуер по поръчка YazSis следва четири етапа:

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

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

Три неща, които да подготвите, преди да започнете

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

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