Можем ли да спечелим, когато губим, или как да намалим разходите за поддръжка

Категория: ИТ бизнес
Етикети:
Наско Атанасов
27.11.2006

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

Единият от начините да се справите с проблема „нежелани и непредвидени разходи“ е да оцените нивото на техническата поддръжка.

Анатомия на директните разходи
За да се постави основа на анализа на разходите, свързани със закупуването на корпоративен софтуер, най-общо може да се използва следната формула:

Цялостната цена на решението = цената на софтуера или лицензната такса + цената на поддръжката + цената на внедряването + цената на експлоатацията

Тежестта на всеки компонент във формулата е:
    1.Цената на софтуера или лицензната такса = 50%
    2.Цената на поддръжката = 20%
    3.Цената на внедряването = 30%
    4.Цената на експлоатацията = 10%

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

Тази формула е основата, върху която трябва да се базира всеки анализ, а тежестта на факторите да даде на потребителите, търсещи решения, база, върху която да започнат.
Вторият критерий за избор на софтуер е да подпишете споразумение за нивото на услугите (service level agreement). Тези, които взимат решения, трябва да дефинират условията в договора. Тъй като поддръжката представлява 20% от общата цена, това споразумение може да бъде доста критичен фактор.

Анатомия на разходите поради пропуснати ползи
След като директните разходи са определени, идва ред на избора на план за поддръжка.
Разходите за пропуснати ползи представляват пропусната полза от избора на конкретното приложение.
Представете си, че даден индивид с определени способности и квалификация получава оферта за работа. Той може да приеме позицията и да спечели заплатата, която му се предлага, или да пропусне възможността, решавалки да продължи обучението си, например. Цената на избора на втория вариант представлява цената на образованието плюс пропуснатите приходи, които е щял да има, ако е избрал позицията.
Сега можете да приложите тази концепция към избора на план за поддръжка от дистрибутора. Истината зад това решение е в сравнението на дистрибуторите. Представете си ситуация, при която има двама дистрибутори, които продават идентични ERP решения, но предлагат различна техническа поддръжка. Организацията, която купува решението, оглежда в двата дистрибутора и ги сравнява. Ако единият има 50% по-добро време за реакция при възникнал технически проблем от другия, то той доставя поддръжка точно в момента, когато е най-нужна на предприятието. Стойността на пропуснатите ползи, които възникват, когато организацията закупи продукта от втория вендор, представлява сумата, която му е платена за поддръжка плюс загубените приходи в момента, когато решението не е работело.
Така че ако първият е с 50% по-бърз от втория, цената на избора на вендор две е равносилна на цената на пропуснатите ползи, която е равна на цената на лиценза плюс другите загуби. Т.е. това решение е с 50% по-скъпо от другото.

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

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


Други примери за индиректни разходи включват средното време, отделено от служителите, за да заработи решението отново, намаленото време, броят на телефонните разговори и e-mail-и, изпратени до звеното по поддръжка на вендора, и общото време, което е било необходимо, за да се разреши проблемът. Тези разходи са свързани директно с фактора време и така създават модел, който предприятията могат да използват, за да оценяват вендорите.
В зависимост от индустрията и типа на приложението могат да възникнат и други разходи.
За да се избегнат тези капани, в които организациите могат да попаднат, има безброй решения, които те могат да използват, за да увеличат производителността си и да намалят риска от загуби.
Единият начин е да инвестират в методология за поддръжка на решението. По отношение на ресурсите основната концепция е инвестиране в оборудване или човешки капитал, като в замяна на това се очакват печалби.
Когато предприятието се нуждае от решение, единият от начините за инвестиция в бизнеса с цел намаляване на загубите е намиране на най-добрите практики за определяне на план за поддръжка. Такъв подход е Information Technology Infrastructure Library. Той определя как компанията да ръководи всеки процес и така да елиминира индиректните разходи и разходите поради пропуснати ползи. Така предприятията могат да минимизират объркването, което ще настъпи, ако решението спре да работи.
Има различни софтуерни приложения, които могат да се използват заедно с методологията, за да се допълнят организационните процеси и да минимизира рискът от неефективна поддръжка. Те могат да включват service management application (SMA) или business activity model (BAM). SMA или BAM ще могат да разпознаят техническите проблеми при тяхното възникване и да докладват за това на ИТ мениджъра, отговорен за решението.
По отношение на техническата поддръжка не е задължително организациите да следват формализиран процес за избора и оценката. Техническата поддръжка е доста важен компонент за всяка организация, притежаваща ERP решение. Финансовите аспекти на лошата техническа поддръжка могат да засегнат общата цена на притежание и възвръщаемостта на инвестициите. Още по-жестоки ще са последствията, ако решението не пасва добре на бизнеса. Лошата поддръжка засяга жизнения цикъл на решението и също причинява проблеми на служителите, които го използват. Това може да доведе до повече стрес на работното място, което също е допълнителен индиректен разход.
Така че когато компанията си търси решение, тя трябва да си отговори на следните четири въпроса:
  • Каква услуга предлага дистрибуторът?
  • Има ли в решението някаква форма на SMA или BAM?
  • Възможно ли е да се намерят препоръки от други потребители или да се разбере колко бързо доставчикът реагира, ако възникне проблем?
  • Какво пише в споразумението? Посочил ли е доставчикът как ще се справи при възникването на проблем и в какъв срок?

Крайните потребители могат да поемат риска, като възприемат ITIL методологията, и така да намалят объркването в случай на проблем.