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

У проекту є замовник. Швидше за все, він же інвестор. Але не обов'язково. Сам інвестор має можливість запустити проект, але не бачить в цьому цілі конкретно для себе. І навпаки, замовник (користувачі) потребують результати роботи проектної команди, але не мають можливість оплатити дані роботи. Загалом, інвестор і замовник взаємопов'язані.

Ми згадали поняття «проектної команди», тому пропонуємо зупинитися на цьому понятті трішки детальніше, щоб обговорити, хто ці люди, що складають команду, як вона формується, управляється, дає результати роботи. Сформувати команду на проект можна кількома способами.

Перше. Можна підібрати людей з вулиці, згуртувати їх навколо лідера, пустити справу в оборот.

Друге. Знайти готову, згуртовану, напрацьовану на проектах команду. Знайти таку важче, і швидше за все дорожче, ніж одиноких шукачів.

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

  Припустимо, з проектною командою ви визначилися і тепер власне вам потрібно вказати їм мету, до якої вони будуть рухатися. Вашу мету. Викласти на словах, обговорити на нарадах можна. Але як кажуть слово до «справи" не прикріпивши. Для обох сторін (замовнику і виконавцю) у цьому випадку краще відразу задокументувати всі побажання і вимоги до запускає проект, щоб у майбутньому спиратися на документ, а не на слова, пред'являючи вимоги до розробників, або розробникам пред'являти результати своєї роботи посилаючись на реальні вимоги до замовленням. Викладом (документуванням) вимог до проекту може бути технічне завдання. Так званий генеральний план на проект. Статут проекту, якщо можна так сказати. І до цього документа не рекомендується підходити легковажно, тому що в майбутньому, як показує практика, у проекту буде безліч каменів спотикання з обох сторін, але база, від якої будуть розплітатися коріння - це все ж технічне завдання. Зрозуміло те, що в ході виконання робіт будуть поправки і прохання, уточнення до вимог, але все ж кістяк буде закладений в генеральному плані. Такі прохання і поправки також рекомендується документувати, взагалі рекомендується все документувати, тому що наперед невідомо куди приведе дорога розробки, а по задокументованим слідах відстежити всі зміни куди легше, ніж згадувати або здогадуватися. До того ж якщо команда як поняття має на увазі роботу над проектом кількох людей, скажімо в одному модулі, додатки можуть писати код два-три програміста одночасно, то невідомо хто і коли вніс зміни, через які вся система полетіла і жорстко приземлилася. Розумно буде уникати таких ситуацій та перед початком проекту приділити час і кошти підготовці технічного завдання. Автором цього документа може бути керівник проекту. На його плечі ляже завдання підготовки передпроектного плану, попереднього ТЗ (0) і узгодження його з замовниками проекту. На це може піти приблизно 20% загального проектного часу. Але як розумієте, приділити цьому час потрібно. Класичний генеральний план розробки (доопрацювання) системи складається з опису мети, методів реалізації та кінцевих результатів. Чим масштабніша проект, тим відповідно ширше описова частина технічного завдання. Наприклад, ERP-система включає в себе багато модулів (виробництво, облік, планування, бюджетування, логістику тощо) і взаємозв'язок між ними обумовлює детальний опис функціоналу системи. Відповідно проект автоматизації такої системи буде дуже великий і детальний.

Обов'язково в ході виконання проектних робіт у, випадку виникнення непередбачених поправок до доопрацювання, вся робота може звестися до нескінченного переробленню і дописування коду вже виконаних робіт. У такому випадку затягування термінів здачі може бути зірвано, що врядли сподобається замовнику. Тому дуже корисним буде розставити, так би мовити «пріоритети» щоб встигнути у заплановані терміни виконати проект і не перевищити при цьому бюджет.

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

Консультант з впровадження 1С

УКРАЇНА
61000 м. Харків, пл. Повстання 7/8, 
  +38(050)978-88-74
  +38(057)761-99-01
   Ця електронна адреса захищена від спам-ботів. вам потрібно увімкнути JavaScript, щоб побачити її.

Консультант з обслуговування 1С

УКРАЇНА
61000 м. Харків, пл. Повстання 7/8, 
  +38(066)131-75-25
  +38(057)761-99-01
   Ця електронна адреса захищена від спам-ботів. вам потрібно увімкнути JavaScript, щоб побачити її.