ИТ решенијата се имплементираат колку да се имплементираат - во превод единствена цел на проектот за имплементација на системот е истиот да заврши со финален аутпут - функционален (технички) систем.
Дефинирање на потребите (requirements) за имплементација врз основа на технички параметри - сосема не земајќи предвид кои се постоечките процеси на работа и како истите би можеле да станат поефикасни преку воведување на ИТ алатка. При воведувањето на системите може да дојде до сериозно усложнување на одредени процеси кои претходно функционирале беспрекорно.
Кратка визија - воспоставување на правила на користење на системот (откако истиот е имплементиран) кои ги задоволуваат само тековните организациски потреби, и не размислување за идните потреби за развој (т.н. "quick fix"). На пример - дефинирање на задолжителни полиња за пополнување во "CRM" софтвер кои еден ден ќе бидат причина за генерирање на погрешни извештаи кои нема да бидат никаква помош на менаџментот при носење на стратешки одлуки.
Тесна визија - односно ограничено гледање на системот што се имплементира како "stand-alone" решение, без да се инкорпорираат во големата слика севкупните ИТ решенија кои ги користи организацијата - во моментот и евентуално во иднина. Ова би значело дека при воведувањето на одреден систем кој за своите потреби користи и креира одредена база на податоци се креира паралелна документација на одредени "настани" кои веќе се архивираат во други системи и бази. Притоа, откако оваа штета е нанесена, понекогаш поминува и премногу долго време во кое се активни овие паралелни системи, и интеграцијата на базите станува се' покомплицирана и секако поскапа.
Кои се вашите искуства во вашата организација? Дали ова се проблеми со кои и вие се соочувате, дали е можеби грешам или нешто недостасува?
Споделете!
5 коментари:
Мислам дека често пати се греши во врска со разликувањето на класичните - „евиденциските“ и ERP системите, и оттука произлегуваат многу проблеми и разочарувања во имплементацијата.
ERP системите имаат две клучни разлики во однос на класичните: автокорективна и автоконтролна функционалност. Тоа значи дека системот има одредена сопствена автономност во контрола на текот на документите и информациите, како и можност да делува корективно на нив.
Многу од потенцијалните усвојувачи на ERP решение не ги земаат предвид овие две карактеристики и не прават доволна подготовка за нивно усвојување.
Ова неразбирање и неподготвеност особено сум го воочил кај средниот управувачки кадар, кој тешко сака да си го „скрши“ комфорот...
Од друга страна, многу компании неточно ги претставуваат своите системи како ERP-enabled (особено кај нас, во Македонија), па тоа создава дополнителна забуна кај корисниците.
Мојата чек-листа за воведување на ERP систем е овде, на мојот блог: http://instantekspert.blogspot.com/2010/03/erp.html
Се додека поимот имплементација нема да го издвоиме од поимот техника ќе имаме проблеми на ова поле.
Значи имплементација постои како наука која мора да е емпириски измерлива со јасни правила кои се учат во школо.
Авторот меша 2 поими: Имплементација и техничка изведба на информациски систем.
(Пр.: Имплементаторите на Рамковниот договор немаат никаква врска со потребата од договорот, составувањето на истиот и потпишувањето. Имплементаторите немаат никаква политичка одговорност, но знаат како тој да заживее.)
По мене, имплементацијата го подразбира целиот процес на воведување на решението (без разлика на тоа од каков тип е), од анализата на потребите, одлука за воведување на системот/решението, преку техничка изведба и на крај мерки за change management.
Мојата перспектива е бизнис и не е осврт на mere ИТ проекти.
Со насловот сакам да кажам дека одлуката за имплементација на одредено решение(целиот процес)многу често има функција да резултира со голо постоење на системот како аутпут. Читајте - менаџментот да се пофали дека "вовел" на пример ЕРП.
Фала за коментарите!
Само сакав да го нагласам погрешниот однос кон производот од сите учесници и дека постојат јасни правила кои ние тука не ги применуваме (некои можеби и не е можно) и на крај завршуваме со прилично депресивни блог постови како овој.
Треба само да се едуцираме и се ќе биде во ред :). Засега, во услови кога едно лице е и комерцијалист и програмер и проект менаџер и имплементатор ќе биде вака како што е, да не заборавиме дека е и газда на фирмата, максимално пристрасен. Истиот непромислено нуди попусти и по 80% а потоа се кае, програмер анализира кориснички потреби без никакви протоколи за работа, без никакви обрасци. Обука врши кој ќе стигне, на кадар кај клиентот кој е со сумлив квалитет, недисциплиниран,.. Се состанчи по цели денови, ништо не се заклучува на состаноците, сите се нервозни (нормално во 20:00 дека ќе се)...
Потреба од ЕРП има само треба: имателот на капиталот ќе најде менаџерски тим кој според постоечки егзактни емпириски модели ќе направи фирма, за да проектите не пропаѓаат.
Програмерите не се супермени и од нив треба да се очекува само да програмираат тоа што од некој ќе им биде наложено.
Баш така! :)
Post a Comment