Реферати українською » Менеджмент » Корпоративна автоматизована інформаційна система коштує як ресурс бізнесу (як поставити ІТ на службу бізнесу?)


Реферат Корпоративна автоматизована інформаційна система коштує як ресурс бізнесу (як поставити ІТ на службу бізнесу?)

Сергій Цодиков, генерального директора групи компаній «Форус»

Використання потенціалу ІТ як стратегічного ресурсу бізнесу – навряд чи хто сьогодні сперечатиметься з важливістю цього твердження. Для серйозних фірм – внедренцев ІТ рішень вона стала майже визначальним гаслом у відносинах із потенційним замовником. Але як реалізується цей потенціал на реальних проектах?

Багаторічний досвід впровадження бізнес додатків дозволяє констатувати – під час проектування автоматизованої інформаційної системи (АИС) учасники проекту, зазвичай, орієнтуються на рішенні операційних проблем бізнесу. Замовник не наполягає вмикання до проекту стратегічних бізнес - вимог, а проектувальник не формулює постановку завдання як стратегічне бизнес-решение. Під словами «стратегічне рішення» ми розуміємо корпоративне інформаційне рішення, орієнтоване отримання стійкого конкурентної переваги бізнесу замовника.

Через війну, потенціал АИС як стратегічного ресурсу бізнесу декларується, але з реалізується у проекті автоматизації. У цьому, про наявність такої потенціалу заявляє всякий пристойний розробник АИС. Вочевидь, що домогтися реалізації потенціалу АИС як ресурсу бізнесу досить складно. Не претендуючи на повноту аналізу, спробуємо накреслити певні «больові» точки проекту АИС, орієнтованого на стратегічних завдань.

Вочевидь, що «стратегічний» потенціал закладається на першої стадії розробки рішення – під час постановки завдання. Звідси випливає, що вона вимагає найпильнішої уваги. Як відомо, в цій стадії відбувається системне опис бізнес – завдання - визначаються і фіксуються ключові чинники проекту: мети, критерії виконання, рамки проекту, опис його результату. Проте досвід участі у мене як виконавець проектів свідчить у тому, що ухвалено рішення бізнес завдань та його автоматизація існують як у різних площинах: бізнес сам собою, а АИС – як така. На думку, у цій рассогласованности й полягає таки головною причиною недооцінки потенціалу АИС як ресурсу бізнесу.  

Скажіть, чи можна назвати розумної причиною побудови АИС ПРОЦЕС автоматизації бізнесу? Навряд, хіба що з безкорисливої любові керівника до ПРОЦЕССУ автоматизації чи як данини до моді. Рациональной причиною застосування АИС у бізнесі є НЕОБХІДНІСТЬ РІШЕННЯ бізнес завдань. Чи це остаточно замовник, а й у виконавець проекту автоматизації? Міркуйте самі. Ось типові уривки з опитувань керівників з постановки завдання й визначенню цілей проекту побудови АИС, які систематично проводяться відділом маркетингу нашої компанії:

1) Директор регіональної компанії: «Мені це треба, щоб необхідна мені інформація мала під рукою. Бажано, щоб кількість її розрізів було максимальним». Спроба уточнення цілей сприяла відповідям: «Я основі інформаційних технологій щось розумію, Ви - «інформаційники», Вас і карти до рук. а тут треба, аби в мене було всього добре з туристичною інформацією: повинна бути своєчасна, точна й багата! Зробіть для мене».

2) Директор великої столичної оптової компанії: «Я стала з прийомом замовлень – не бачу я забезпеченість замовлення товарної продукцією. Добре, якби знати - який товар перебуває: складі, зарезервований замовлення і який термін, їсти дорогою, в комплектації. Ось якби що робити це, в мене було б проблем. Це і суть нашого замовлення розробці АИС».

3) Директор виробничої компанії: «Ми заклали до бюджету на ІТ. Йдіть до бухгалтеру/директору по ІТ – он/они Вам все розповість».

Водночас у першій-ліпшій нагоді питання про необхідність впровадження неодмінно САМІЙ СУЧАСНІЙ АИС під не ставився.

Про що говорять ці два приклади? У перший варіант відбулася підміна цілей побудови АИС характеристиками інформації. Исполнителю проекту пропонується самому сформулювати мети побудови АИС, що означає у разі, не багато немало - сформулювати мети бізнесу замовника. Не так парадоксальна ситуація? Неуспіх проекту просто запрограмований.

У третьому разі мети бізнесу підмінюються частковими і, забезпечують цілями функціональних підрозділів. Питання, чи знають там мети бізнесу? Гроші буде витрачено із високим рівнем контролю, ось тільки під який розумний бизнес-результат?

Другий приклад виглядає здавалося б чіткіше інших. Але, власне, він становить завуальовану різновид третього випадку. У ньому ключовою завданням оголошується контрольна функція АИС. Навряд його можна назвати метою бізнесу. Проте, закріпивши мети проекту на контракті, проект отримує бути, реалізують і оголошується успішним. Інакше кажучи, замовник ефективно витратив гроші. У цьому не врахували втрачено, що первинної метою бізнесу не трата, хоча й ефективна, а ЗАРАБАТЫВАНИЕ грошей.  

Отже, ключова проблема успішного проекту АИС у тому, як замовник розуміє цьому проекті: як витратний чи як інвестиційний. Багаторічний досвід роботи показує, що тільки 4 - 5 %% керівників ставлять перед проектом впровадження АИС справді інвестиційні завдання. Інакше кажучи, необхідною умовою успішності проекту АИС має стати його націленість на кінцеві, а чи не проміжні мету і результати бізнесу.  

І тоді починається найцікавіше. При спробі прояснити мети бізнесу, розмову з керівником компанії до болю нагадує алегоричне діалог Аліси і Чеширского кота з оповідання Льиса Керролла «Аліса країни чудес»:

« - Скажіть будь ласка, куди мені звідси йти? – запитала Аліса.

- А куди ти хочеш потрапити? – відповів Кот.

- Мені однаково… - сказала Аліса.

- Тоді всі одно, куди й йти – зауважив Кот».

На жаль, з нашого практики, значну кількість компаній намагаються досягти результатів, які мають чіткого уявлення, якими повинно бути. Отже, виявлення і чітка формулювання мети бізнес роботи і АИС як однієї з ресурсів її досягнення є критичною завданням першої фази проекту АИС. Але як його виявити? Вочевидь, цього потрібно:

1. Доступ розробників АИС до керівництва компанії замовника, яке потенційно є «носієм» знання про цілі і дійсних проблемах своїх бізнесів.

2. Наявністю розробник АИС фахівців, компетенцій і технології виявлення і формулювання бізнес завдань замовника. Ці фахівці повинні володіти як знаннями й навиками системного аналізу, а й уміти ставити і аналізувати бізнес – завдання мовою бізнесу. Справді, навіть якщо ви вдасться одержати доступом до керівництву компанії замовника, годі особливо на те, що його зуміє відразу дати вам ясні і що зрозумілі роз'яснення цілей компанії. Виявлення цього є итерационным процесом, які вимагають нетривіальних зусиль, спеціальних знань застосування спеціальної техніки з вироблення узгодженого бачення розв'язуваної завдання учасники проекту АИС.

3. Компетентність розробника АИС – його спроможність переводити бізнес – завдання у мети проекту АИС.

Слід зазначити, що нинішня теорія проектування АИС, хоч і підкреслює важливість фази виявлення вимог до АИС, виходить із припущення, що мета, бажане стан об'єкта автоматизації, отже - вимоги до АИС, відомі замовнику на початок проекту. Разработчику необхідно сформулювати, зафіксувати і схвалити їх в замовника під час системно-аналитического обстеження підприємства. Це становище закріплюється як базове в усіх навчальних програмах з підготовки АИС фахівців. Воно постає як якийсь вододіл між бізнес - і ІТ консалтингом. І оскільки його «так навчали й так належить», розробник АИС поводиться у відповідність із принципом «чого зволите», виконуючи АИС проект оскільки ніби учасники виробили узгоджене, точне і певний розуміння мети клієнта. І розробник АИС проводить опитування, виявляє і аналізує вимоги замовника, що з високою ймовірністю не відповідають його бізнес цілям. Не тут чи лежать причини скептичних зауважень частини топ менеджменту про непотрібність АИС, про нечесних і корисливих информационщиках, тільки і думаючих у тому, щоб більше заробити на погано котрі знаються на особливостях інформаційних технологій керівників?

За виконання проекту побудови корпоративної АИС з нашого практиці прийнято виходити із інший посилки: мети АИС проекту слід обов'язковим чином виявляти та узгоджувати з замовником. Причому тільки у контексті бізнес цілей підприємства замовника. Ми виходимо з принципу, що значно важливіше чи, як стверджує теорія проектування АИС, бо, що правильно й працює практично.

Проілюструємо підхід і оцінимо його результативність з прикладу впровадження АИС одного з наших замовників.

Керівник ІТ служби замовника ініціював проекту автоматизації підрозділи експедиції хлібокомбінату. У його трактуванні проблема, потребує автоматизованого рішення, полягала у невисокою швидкості обробки транзакцій існуючої АИС у бойових операціях відпустки хліба оптовим споживачам. Це призводила до того, що, служба експедиції не могла оперативно відстежувати залишки хліба по сортам у процесі відвантаження. Працюючи «наосліп», служба дозволяла відвантаження хліба, зарезервованого під гарантовані замовлення: дитячі садки, зі школи і т.д. Побічним ефектом була низька швидкість обслуговування: машини споживачів ставали з п'ятьма –ти ранку, а обслуговування займало чимало часу.

У відповідність до заявленої метою, нами було зроблено технико-коммерческое пропозицію щодо розробки і впровадження АИС, що дозволяє прискорити роботу існуючої АИС в 3 разу. Включення у процес переговорів із комерційним директором формально вартість і термінах виконання проекту бізнес – консультанта, застосував технологію процессного консалтингу, дозволило за іншим побачити мети побудови АИС. У результаті переговорів бізнес – консультанту вдалося, що ключовий бізнес - завданням підприємства було встановлення оптимальних витрат виробництва хліба. Задействуя три печі із виробництва хліба (повна потужність), завод забезпечував хлібом всіх охочих споживачів, але мав високий рівень повернення черствого хліба через свої роздрібні точки. З використанням двох печей з'являвся дефіцит хліба.

Виявлена проблема призвела до переформулировке початкової мети проекту автоматизації. Метою стала розробка не транзакционной, а аналітичної АИС з виявлення і моніторингу цільових клієнтів - і їх потреб. Завдання було сформульовано як аналіз складу клієнтів, структури замовлення й визначення рівнів обслуговування споживачів. Аналітична АИС дозволила встановити на такому факті: з більш як 500 оптових споживачів, 80 % обсягу збуту в грошах забезпечували трохи більше 120 їх. У цьому і обсяг, і структура потреб цих клієнтів добре корелювали з потужностями двох, а чи не трьох печей. У цілому нині, проект розробки аналітичної АИС переорієнтувався для досягнення бізнес цілей: фокусі на цільових споживачах і номенклатурі своєї продукції, відповідної потребам цільових споживачів. Реалізація цього проекту призвела до зменшення рівня витрат та збільшення втрат при поліпшенні рівня обслуговування цільових клієнтів, список яких був виявлений, які обслуговування організовувалося в пріоритетному порядку. Описаний приклад показує, як шляхом уточнення на стадії постановки цілей вдається досягти перетворення АИС в ефективний ресурс бізнесу.

Отже, процессный консультант до початку проекту АИС, разом із замовником має чітко й зрозуміло сформулювати відповіді такі «прості» питання:

- Яке нинішнє становище бізнесу замовника?

- Які напрями рухається бізнесу та його пріоритетність?

- Чим обгрунтовані обрані пріоритети?

- Яке бажане стан і цілі бізнесу?

- Які завдання слід вирішити, аби домогтися бажаного стану?

- Які порядок вирішення завдань і, які сигналізують, що розв'язання цієї досягнуто?

- Що варто робити наступним кроком?

- Отримані що з замовником відповіді й дозволяють сформувати узгоджене бачення цілей, завдань, критеріїв проекту. Вони утворюють своєрідну дороговказну нитку в успішному проекті побудови АИС, націленому для підвищення ефективності бізнесу.

Наприкінці підкреслимо вкотре, що з реалізації описаного підходу розроблювач повинен мати технологічні компетенції і навички, вміння ефективно організувати взаємодію Космосу з клієнтом, мати перевіреної технологією та дисципліною виконання проекту. Саме у компанії "Форус" приділяється максимальна увага до з розробки й постійному вдосконаленню технології процессного консультування, формуванню компетенцій в ІТ- й бізнес – консалтингу, умов реалізації цій технології в проектної практиці.

Список літератури

Друкер П. Завдання менеджменту в ХХI столітті. – М.: Видавничий будинок «Вільямс», 2000.

Гейтс Б. Бізнес зі швидкістю думки. – М.: Вид-во ЭКСМО-Пресс, 2001.

Керрол Л. Аліса країни чудес. – М.:Наука, 1990.

Уїлсон З., Мэйплс Б., Лэндгрейв Т. Принципи проектування й розробки програмного забезпечення. – М.: Издательско-торговый будинок «Російська Редакція», 2000.

Kendall K, Kendall J. Systems Analysis and Design. – New Jersey: Prentice – Hall, Inc., 1988.

Схожі реферати:

Нові надходження

Замовлення реферату

Реклама

Навігація