4 Ключові проблеми проектів впровадження ПО 1С Підприємство
Від чого статистика так сумна? Чому проекти валяться один за іншим? Ось вам ще одна точка зору на цей факт
Отже. Проект завалений. У чому причина?
Причин звичайно можна назвати багато. На кого не подивися, явно на причину схожий! І розбір польотів можна робити до посиніння.
Ключова проблема в тому що впровадженням займаються програмісти. Хоча це завдання управлінська. Тільки людина з компетенціями керівника, здатний доводити дії до результатів, незалежно від труднощів.
Розбираємо ...
Для впровадження потрібні 3 ключові ролі (моя версія):
керівник проекту (той хто доб'ється результату, може залучатися з боку)
програміст (спеціаліст знайомий з програмою, і тим як виглядають процеси при її використанні, може залучатися з боку)
фахівці з поточним процесам (як правило внутрішні співробітники, бажано поадекватней, хоча грамотний РП вивудить потрібну інформацію навіть з п'яного бабуїна)
Для впровадження потрібні 3 ключові ролі (версія В. Тарасова, © Управління з Макіавеллі):
Фанат: той хто знає як виглядає кінцевий результат, і не боїться вступати в конфлік, захищаючи ідею, якщо хтось вирішив вводить протиріччя в проект, намагається все повернути на колишні місця;
Менеджер: той хто зуміє поєднати старі порядки, з новими, напише інструкції ...;
Хрещений батько: той чия сила забезпечує рух проекту, той хто може застосовувати адміністративний ресурс;
В обох варіантах ролі увазі лише ролі. Вони можуть відповідати одній людині або декільком. Важливо щоб вони були.
Крім людей знадобиться комп'ютер, сама програма і листок паперу
Якщо прибрати в сторону товсті книги по PMI, PM BOK, Agile ... Ключові правила, порушення яких призводить до провалу проекту. Правила дуже прості. Але порушуються в 99% випадків.
Ось вони :)
Правило №1. Щотижневі нараду на чолі з керівником проекту (РП). Керівник проекту задає питання, дає завдання, з однією лише метою ... виконати правило №2.
Правило №2. За підсумками кожного наради потрібно робити звіт про стан проекту, який потім розсилається всій групі. Звіт дуже простий, та супер ефективний, що складаються з 3х розділів: 1. Результати за підсумками минулого період, 2. План дій на найближчий період, 3. Виявлені проблеми. Навпроти кожного важливого пункту, терміни і відповідальні. Можна додавати розділи ще, але це ключові та обов'язкові. Вони оновлюються за підсумками кожного наради.
Правило №3. Користувачам потрібні інструкції. Але інструкції по процесам і функціям, а не об'єктах та функцій програми, котрі йдуть в комплекті. Відмінність істотне і їх розглянемо нижче
Правило №4. Служба технічної підтримки, здатна вирішувати складні технічні проблеми і знаходити рішення помилок. Може бути віддалена. Але надійна. Тому якщо немає поблизу можна купити кого небудь через Інтернет.
А ось тепер подробней по кожному пункту.
За правилом №1. РП це ключова фігура. Можна порушити будь-які правила і зіпсувати все що завгодно, але якщо РП гідний то він вирулить. Але якщо РП немає або замість нього Опудало, тоді на кожній нараді будемо узновать про те що у нас знову що щось не так і терміни будуть звучть «ну ось ще пару тижнів і все буде» або «так ми майже закінчили, потрібно тільки почати да кінчити », або« не знаю термінів, тут багато всяких нюансів », а може бути РП звинуватить всіх у всьому, скаже що всі дурні, що у провалі проекту винен той, той або той, а він зробив все що міг.
За правилом №2. Звіт це ключ від дверей де гроші лежать. У розділі Результати пишемо що було зроблено за минулий тиждень, і всі ті результати які досягнуті по ходу проекту. У розділі План пишемо ті дії які плануються, відповідальні, терміни, на наступний період. У Проблемах пишемо якісь труднощі які призводять до пробуксовки, і відповідальних. Це може бути сам РП, програміст, користувач, або служба технічної підтримки. Звіт оновлюється за підсумками наради. Розсилається проектній групі. І так до наступної наради. На наступному сідаємо, проходимся по пунктах, термінів, ответсвтенним. Якщо термін порушений, то треба зробити все можливе, щоб людині більше не захотілося порушувати дане їм слово. Загалом добиваємося того щоб наступного разу ставили або більше реальні терміни або кров з носу виконували ті що встановили.
За правилом №3. Програма це вторинне. Запустити систему можна і без програми. А от організувати процес без інструкцій це синку фантастика. Інструкції це основа системи. Але інструкції не ті що йдуть в комплекті з 1С Підприємство. З тими інструкціями можна йти вогнище розпалювати. Користувачам від них толку мало, тому ці інструкції написані програмістами для програмістів. Книги теж дають мало користі, особливо новачкам. Інструкція повинна бути написана з точки зору процесів і процедур. Повний порядок дій, від А до Я з картинками. Плюс умови при яких процес починає гілкуватися і виляти, всі можливі петлі. Мовляв якщо це тоді ось туди. Такі процеси йдуть з розвиненими продуктами типу SAP, Navision, DIRECTUM, там де культура впровадження розвинена і є відповідна категорія фахівців. А ось в 1С цієї категорії немає і відповідно знань цих теж. Є програмісти, які не в курсі що таке інструкції для користувачів, що таке процеси, що таке ТЗ на впровадження. Вони їх плутають з інструкціями за програмою, а також з ТЗ на розробку, думаючи що це одне і теж або щось схоже.
За правилом №4. 90% організацій продають або впроваджують 1С досі ставляться до тех.підтримки як до чогось то мало важливого. Звернень від користувачів залишаються без реєстрації, губляться, забуваються, забиваються. Контролю термінів немає. Довіру користувачів втрачаємо в перші ж секунди співпраці.
Резюме
Не треба вчити розумні книги і залазити в нетрі теорій. Це дуже прості правила. Які потрібно лише постаратися виконати. Я розумію що знайти РП з п.1 в наш час складніше ніж почухати ногою за вухом, але піде будь-яка людина з організаторськими компетенціями який зможе виконати інші 3 пункту.
