КЛУБ ПРОГРАММИСТОВ ДЛЯ ШКОЛЬНИКОВ

1С:Учет в управляющих организациях ТСЖ, ЖКХ и ЖСК


Управление проектом автоматизации розничного магазина

Печать PDF

Кулешов Дмитрий, фирма 1С24.07.2009

Введение

Розничная торговля - одна из вечных отраслей. Пока у человека есть потребность в еде и одежде, а такая потребность в обозримом будущем у человека точно будет, для розничной торговли работа найдется. Она может менять форму и содержание, но суть остается неизменной на протяжении веков.

В 70-80-х годах прошлого века в розничную торговлю, как и во многие другие отрасли, пришли информационные технологии и произвели в ней настоящую революцию. В розничной торговле появилась новая форма - супермаркеты и гипермаркеты самообслуживания, для которых информационные технологии, несомненно, являлись одним из конкурентных преимуществ. А для «традиционных» малых форматов розничной торговли настали тяжелые времена, продолжающиеся и по настоящий день. Малому бизнесу информационные технологии были не по карману. Персональный компьютер стоил как автомобиль, а разработка и поддержка программного обеспечения для существовавших тогда платформ еще дороже. Кроме того, «малый бизнес» в то время в нашей стране назывался «спекуляция» и описывался статьями Уголовного Кодекса СССР. Да и понятия розничной торговли как таковой не существовало. В плановой экономике вместо торговли было распределение товаров народного потребления. В сложившейся ситуации информационные технологии ничем не могли помочь торговым предприятиям.

Ситуация в корне изменилась с появлением в 80-х годах прошлого века платформы PC и операционной системы MS DOS. Сегмент информационных технологий для малого бизнеса начал свое стремительное развитие. Многие помнят такой замечательный продукт как FoxPro, послуживший платформой для автоматизации торговли множества предприятий. Пожалуй, именно с него в нашей стране и начали свое развитие информационные технологии в розничной торговле.

Сегодня к услугам малого бизнеса множество решений для автоматизации торговли, относительно недорогие компьютеры и электронное торговое оборудование. Грамотное применение всего этого арсенала позволяет малым форматам розничной торговли конкурировать с большими розничными сетями. Но разобраться в изобилии предложений и выбрать именно то, что нужно Вам, не имея специальных знаний в области информационных технологий, нелегко. Тем более что все поставщики наперебой расхваливают свои решения как идеально подходящие именно Вам, да и цена вопроса от поставщика к поставщику варьируется не сильно.

Этот материал будет интересен, прежде всего, предпринимателям, занятым в малом бизнесе. В статье будут рассмотрены практические аспекты управления проектом автоматизации розничного магазина или небольшой сети магазинов формата «у дома». Описываемые подходы основаны на классических принципах проектного управления и применимы к большинству предлагаемых на рынке программных продуктов.

1. Цель проекта

Для того, чтобы в результате проекта получить то, что нужно Вам, а не кому-либо другому, нужно четко сформулировать цель. Задайтесь вопросом: зачем нужна автоматизация магазина? Вариантов ответа может быть несколько. Например:

  1. Чтобы получать больше прибыли
  2. Чтобы перевести магазин на формат самообслуживания.
  3. Чтобы предотвратить воровство персонала.
  4. Чтобы сократить очереди, ускорить обслуживание покупателей.
  5. Все автоматизируют - значит нужно!

Все эти ответы можно, конечно, считать целью, ну разве что за исключением №5. Вполне достойные цели для проекта. Но внедрение системы автоматизации напрямую не ведет к достижению этих целей. Вполне может оказаться, что основная часть покупателей магазина - пенсионеры и не приемлют формата самообслуживания. Информационная система не ловит воров за руку. С системой работают люди и воруют тоже люди, и если не принимать комплексных мер, они научатся обходить запреты системы. Да и скорость обслуживания и тем более прибыль никак не зависят от применения информационных технологий. Очевидно, что для достижения этих целей нужны комплексные меры, включающие в себя информационные технологии, но ими не ограничивающиеся.

Всякий бизнесмен думает о том, как сделать свой бизнес эффективнее. Как получать больше прибыли с каждого вложенного рубля, с квадратного метра торговой площади, с каждого нанятого работника. Именно в контексте эффективности бизнеса и следует рассматривать проект автоматизации.

Внедрение информационной системы само по себе не приведет к повышению эффективности бизнеса. При необдуманном подходе оно даже может ее снизить.

По сути, любая информационная система представляет собой упрощенную до требуемого уровня модель реальности. Не являются исключением и системы автоматизации магазинов. Они моделируют работу магазина и могут позволить Вам контролировать все его бизнес-процессы.

Если Вы в состоянии самостоятельно контролировать все, что происходит в Вашем магазине, то можете считать свой бизнес самодостаточными и отложить идею внедрения системы автоматизации до той поры, когда контролировать все самому станет сложно. Если же у Вас есть сомнения в собственной осведомленности относительно тех или иных процессов, происходящих в Вашем магазине, то это повод задуматься о том, как пролить свет на эти таинственные процессы.

Сделать бизнес управляемым - вот достойная цель для проекта автоматизации магазина. Достигнув этой цели можно двигаться дальше, т.е. повышать эффективность бизнеса - открывать магазин самообслуживания, бороться с воровством персонала, ускорять обслуживание покупателей и увеличивать прибыль.

Хорошо поставленная цель должна удовлетворять критериям SMARТ. Аббревиатура от английского Specific Measurable, Achievable, Result-oriented, Timed. Это означает, что цель должна быть (S) конкретной, (M) измеримой, (A) достижимой, (R) ориентированной на результат и (T) определенной во времени.

Т.е. приведенное выше определение цели недостаточно и требует доработок.

Цель нужно конкретизировать. Определить, какой именно бизнес, например, основную деятельность магазина «Продукты».Определить каким образом, например, автоматизировав основные бизнес-процессы при помощи электронного торгового оборудования и автоматизированной системы управления.

Цель должна быть измерима. В данном примере необходимо определить рамки. В каких пределах будет проводиться автоматизация? Например, потребуется ли автоматизировать отчисления за аренду или коммунальные платежи? Скорее всего нет - это косвенные расходы, они и без того находятся полностью под контролем. А, например, процессы закупки товара, возврата, розничной продажи, взаиморасчетов с контрагентами нужно автоматизировать. Ну и конечно, если в Вашем бизнесе более одного объекта, нужно конкретизировать географические рамки проекта, какие именно магазины, склады и офисы будут подвергнуты автоматизации.

Попробуем проанализировать достижимость цели. Приведет ли автоматизация к достижению желаемой управляемости бизнеса? Ответ на этот вопрос не столь очевиден, как кажется на первый взгляд.

Приведем такой пример, допустим, конкретизируя цель, Вы решили поставить под контроль сроки годности товара, таким образом, что бы в первую очередь продавать товар с наименьшим остаточным сроком годности.

Организовать в автоматизированной системе списание товара в соответствии с принципом FEFO* никаких проблем не составляет. Но как проконтролировать, что в действительности первым уйдет товар с наименьшим сроком годности? Товар, выложенный в торговом зале магазина самообслуживания, продается ровно в обратном порядке - покупатели кладут в корзины товар с наибольшим сроком годности. Соответственно возникает задача своевременной выкладки товара в торговый зал. Но как определить, когда в торговом зале заканчивается очередная партия товара? Автоматизированная система никак не может определить, находится ли товар на полке, или в корзине покупателя до момента его оплаты на кассе. Соответственно эта задача возлагается на продавца в торговом зале. Он должен следить за состоянием полок, что он и так делает, и своевременно их пополнять, что он и так делает.

Как только заканчивается товар, продавец идет на склад магазина и перемещает очередную партию для пополнения полки. Вот именно в этот момент и нужно проконтролировать, что бы это перемещение соответствовало принципу FEFO. А тут ключевую роль играет человеческий фактор и культура учета на складе. Решение этой задачи находится в административной плоскости и не требует каких-либо специальных решений в системе автоматизации, где такая цель не достижима. Достаточно иметь квалифицированного и дисциплинированного кладовщика «вживую» организующего на складе принцип FEFO и выдающего продавцам товар именно из партий с минимальным остаточным сроком годности.

Ориентирована ли выбранная цель на результат? Есть две крайности, можно поставить цель «ходить на работу» - один подход, можно поставить цель «достигнуть какого результата на работе» - другой подход. «Сделать бизнес контролируемым» ближе ко второму подходу, т.е. сам по себе контроль над бизнесом можно условно считать результатом, а вот достижения контролируемого и управляемого бизнеса, вне всякого сомнения, является результатом.

Скорее всего, идея автоматизировать магазин возникла не на пустом месте, а как задача какого-то более амбициозного плана, например, по увеличению объема продаж, и в этом случае результат следует рассматривать целиком, в общей пирамиде целей. Вершину пирамиды образует глобальная цель, например, увеличение объема продаж на 120% по сравнению с прошедшим годом, а такие цели как переход на формат самообслуживания, открытие нового магазина и автоматизация являются теми блоками, которые формируют пирамиду.

И наконец, нужно определиться со временем. Когда магазин должен быть автоматизирован? В большинстве случаев ответ на этот вопрос - вчера. Для рассматриваемого в этом материале в качестве примера магазине формата «у дома» оптимальным сроком внедрения считается две недели. Не рассчитывайте на более сжатые сроки, пострадает качество. Не доверяйте заявлениям «Сделаем быстро, качественно, дешево - выберите любые два». Эти работы невозможно сделать быстрее, заплатив за них больше и привлекая к ним большее количество исполнителей. Для рождения ребенка нужна одна женщина и девять месяцев, девять женщин никак не родят ребенка за один месяц.

Невозможно обучить персонал, не инсталлировав систему, невозможно инсталлировать систему, не подготовив локальную вычислительную сеть и не поставив электронного торгового оборудования. Две недели это оптимальный срок, если не возникнет никаких накладок. А накладки имеют свойство возникать именно тогда, когда все надеются, что их не будет.

Итак, цель определена, она конкретна, измерима, достижима, ориентирована на результат и определена во времени. Это уже не мало. Информационные технологии знают достаточно примеров проектов, в которых не было четко сформулированных целей. Некоторые из них были успешными, но это скорее исключение, чем правило.

Зафиксируем цель. Откройте любой текстовый редактор, и создайте в нем новый документ. Назовите его «Устав проекта». И добавьте в него первый раздел «Цель проекта». Формализуйте и запишите, какие именно бизнес-процессы, в каком именно магазине и как требуется контролировать. В какой срок вы ожидаете запуск системы в эксплуатацию, и к какому сроку ожидаете результатов от ее эксплуатации.

В дальнейшем мы не раз будем обращаться к Уставу проекта и Цели проекта для принятия тех или иных решений и оценки результатов. Цель можно будет уточнять, конкретизировать, дополнять. Не рекомендуется ее менять на диаметрально противоположную - это, как минимум, перечеркнет все те усилия, которые были приложены к достижению ранее определенной цели.

Создайте в Уставе проекта еще один раздел, назовите его «Участники проекта», и впишите в него себя, указав свою роль «Руководитель проекта».

С этого момента проект считается инициированным.
Теперь нам предстоит определить требования.

НАВЕРХ

2. Требования

Разобравшись, для чего Вам нужна автоматизация магазина, можно приступать к следующему этапу - определения того, какими свойствами должна обладать система автоматизации Вашего магазина.

Требования - это совокупность утверждений относительно свойств системы. Различаются бизнес требования и системы системные требования.

Бизнес требования определяют назначение системы, ограничения, проистекающие из отраслевой специфики и свойств бизнеса.
Системные требования определяют элементарные операции, которые должна поддерживать система и различного рода условия и ограничения на ее работу.

Для формализации требований используются простые текстовые описания и различные графические модели.

Формирование требований начинается с определения рамок проекта: организационных, географических, временных и функциональных.

Невозможно охватить системой автоматизации все. Определив рамки проекта, Вы фиксируете границы, в которых ожидаются результаты проекта. Если этого не сделать, то проект будет бесконечно расширяться во времени и бюджете, и самое главное - никогда не достигнет результата.

Организационные рамки определяют, в каких подразделениях проводится проект. Юридические лица, магазины, склады, отделы и прочие элементы организационной структуры предприятия могут быть затронуты проектом. Для определения организационных рамок нужно выписать те элементы, которые будут вовлечены в проект. Например, это можно описать так: «Учредитель, Магазин №1, Магазин №2, Склад».

Географические рамки определяют местоположения объектов, на которых ведется проект. Например, от того в одном или разных городах расположены объекты будет зависеть структура проекта, архитектура системы и бюджет. Для описания географических рамок достаточно перечислить адреса объектов, входящих в рамки проекта.

Временные рамки определяют дату начала, завершения проекта и основные этапы проектных работ. Про этапы работ будет рассказано в главе о планировании проекта, пока что определите оптимальную дату для начала работ и желаемую дату начала эксплуатации системы.

Самое сложное - это определение функциональных рамок проекта. По сути это основные бизнес требования к системе, или как их еще называют требования первого уровня. Для их корректного описания хорошо бы иметь некий структурный анализ бизнес-процессов, которые требуется автоматизировать. Один-два уровня в таком структурном анализе вполне могут сойти за описание функциональных требований. Например, это может выглядеть так:

1. Управление ассортиментом 
1.1. Ввод новой ассортиментной позиции
1.2. Замена/изъятие ассортиментной позиции 

2. Управление ценообразованием 
2.1. Назначение розничной цены
2.2. Переоценка 

3. Розничная торговля в формате самообслуживания с применением штрихового кодирования товара 
3.1. Продажа за наличные
3.2. Продажа по банковским картам
3.3. Продажа со скидками
3.4. Возврат от покупателя через кассу
3.5. Прием платежей сотовых операторов
3.6. Передача смены кассира 

4. Поступление товара в магазин 
4.1. Прием электронной накладной от поставщика
4.2. Прием товаров по ордерной схеме, фиксация расхождений
4.3. Штрих-кодовая маркировка товара
4.4. Установка розничных цен
4.5. Печать ценников
4.6. Формирование заказов поставщикам 

5. Внутренние перемещения товара 
5.1. Подпитка торгового зала
5.2. Возврат из торгового зала 

6. Инвентаризация 
6.1. Частичная инвентаризация по товарным группам
6.2. Полная инвентаризация по складам 

7. Управление лояльностью покупателей 
7.1. Простая процентная скидка
7.2. Накопительная скидка
7.3. Бонусная программа 

8. Анализ деятельности магазина 
8.1. Анализ валовой прибыли
8.2. Анализ товарных запасов
8.3. Анализ оборачиваемости товаров
8.4. Анализ нагрузки на кассы 

9. Бухгалтерский учет в соответствии с РСБУ

Проанализируйте в подобном ключе структуру бизнес-процессов Вашего магазина, обязательно зафиксируйте то, что считаете важным. Например, если у Вас работают продавцы в торговом зале и они мотивированны на продажи, в функциональные рамки нужно включить соответствующие функции сопоставления продаж на кассе и продавцов в торговом зале, аналитику продаж в разрезе продавцов, возможно, какие-то алгоритмы для расчета бонуса продавцам. На данном этапе не стоит углубляться в детали и формализовать, как именно Вы собираетесь мотивировать продавцов, этим мы займемся чуть позже в этой же главе.

А пока что откройте Устав проекта и добавьте в него раздел «Рамки проекта». Опишите организационные, географические, временные и функциональные рамки проекта. В дальнейшем мы будем неоднократно сверяться с этим разделом, и в зависимости от ситуации отказываться от новых требований или расширять рамки, если новые требования выходят за рамки проекта.

Продолжим работу с бизнес требованиями. Собственно, эта работа будет вестись на протяжении всего проекта, на данном этапе мы определим только ключевые требования, которые повлияют на принятие основных решений в проекте.

Существуют различные методики выявления требований. Большинство из них основано на опросе будущих пользователей, анализе и систематизации полученной от них информации. Для выявления ключевых требований нужно определить ключевых пользователей.
Вернемся к структурному анализу бизнес-процессов, при помощи которого мы определили функциональные рамки. Рассмотрим первый уровень и напротив каждого блока укажем человека, ответственного за эту деятельность. Вполне может оказаться, что за все блоки окажетесь ответственны Вы лично, для малого бизнеса это вполне нормально.

 

Бизнес-процессы Ответственный
1 Управление ассортиментом
2 Управление ценообразованием
3 Розничная торговля
4 Поступление товара
5 Внутренние перемещения
6 Инвентаризация
7 Управление лояльностью покупателей
8 Анализ деятельности
9 Бухгалтерский учет по РСБУ

 

Откройте документ Устав проекта и добавьте ключевые пользователи в раздел «Участники проекта», присвоив им соответствующие роли.

Возможно, что за один блок бизнес-процессов в таком списке будет отвечать более одного человека. Такая ситуация будет создавать путаницу в дальнейшем и ее нужно пресечь на раннем этапе. Попробуйте разделить блок на два или более и назначить на них по одному ответственному. Или выберите из нескольких ответственных самого ответственного, а остальных исключите из списка.

Откройте текстовый редактор и создайте в нем новый документ. Назовите его «Требования».

Требования удобно описывать в виде таблицы примерно такого вида:

 

Владелец Описание
1
2

 

Если Вы попали в этот список, с Вас и начнем. Задайте себе вопрос: без чего процесс никак не может обойтись?

Если у Вас круглосуточный магазин 24х7, очевидно потребуется непрерывная работа системы. В соответствии с Законом о применении контрольно кассовой техники Вы обязаны оформлять продажи через кассовые аппараты, внесенные в Государственный реестр контрольно-кассовой техники. Очевидно, потребуется интеграция в систему кассовой техники - это бизнес требование. Посмотрите, какая кассовая техника у Вас используется, если ее можно использовать в автоматизированных системах определите системное требование поддержки именно Ваших моделей касс. То же самое касается терминалов приема платежей по банковским картам, современные модели которых могут быть интегрированы с программным обеспечением.

Анализируя бизнес- процессы поступления товара обратите внимание на системы электронного обмена данными с поставщиками. Если есть возможность их использовать, создайте бизнес требование, определяющее саму возможность электронного обмена данными, в дальнейшем на его основе Вы можете создать системное требование, в котором будут описаны форматы данных, способы их передачи и т.п.

Для описания требований к системе лояльности покупателей следует обратить внимание на используемые виды скидок, интеграцию с процессинговыми центрами. Сначала определяйте бизнес требование, описывающее саму возможность использования той или иной скидки, правила ее применения. Системные требования, описывающие спецификацию магнитных карт, протоколы обмена с процессинговым центром можно описать позже.

Используйте полученные Вами требования как образец и опросите остальных ключевых пользователей.

Работа с требованиями процесс увлекательный. Опрашивая ключевых пользователей можно услышать много странного, ведь «у кого о чем болит...». Кто-то из ключевых пользователей когда-то где-то работал, и у него были такие проблемы, о которых он считает необходимым сообщить, если речь заходит о требованиях. Собирая требования необходимо четко определять, где заканчиваются бизнес-требования и начинаются системные требования. Как только это происходит, ключевые пользователи полностью переключатся на системные требования, и здесь следует остановиться. На данном этапе этой информации Вам достаточно. Объясните им, что процесс работы с требованиями итерационный и в дальнейшем Вы не раз к ним вернетесь, уточните и дополните все, что сочтете нужным, но сейчас подобная детализация является излишней.

Проведите инвентаризацию Вашего информационно-технического хозяйства. Подсчитайте количество компьютеров на рабочих местах, перепишите их технические характеристики. Опишите характеристики локальной сети. Особое внимание уделите электронному торговому оборудованию, в первую очередь контрольно кассовой технике, электронным весам. Это дорогостоящее оборудование и Вы заинтересованы в сохранении вложенных в него инвестиций. Если торговое оборудование способно интегрироваться с системой автоматизации магазина, создайте соответствующее системное требование. Так же создайте системное требование, в котором опишите компьютер с самыми слабыми характеристиками (процессор, оперативная память, жесткий диск, графическое разрешение экрана), который остается в Вашем хозяйстве, и назовите его «Минимально допустимые параметры рабочего места для работы системы».

После того, как требования собраны, необходимо провести их анализ, прежде всего на непротиворечивость. Вполне возможно, что один ключевой пользователь создаст требование, противоречащее требованию, созданному другим.

Наиболее распространенная зона конфликтов требований находится на пересечении коммерческой деятельности и бухгалтерского учета. Общеизвестно, что по стандартам бухгалтерского учета нельзя продавать товар с нулевой наценкой или ниже себестоимости. Однако в розничном магазине нередко возникает необходимость продать товар ниже закупочной цены, что бы ни понести еще большие потери. Вам нужно выявить и разрешить все такие конфликты требований.

Итак, у Вас есть проектная команда, и есть первая редакция проектных документов:

  • Устав проекта
  • Требования

Самое время согласовать документы. Добавьте в эти документы лист согласования примерно такого вида:

 

ФИО Версия Дата Замечания Подпись
1 1.0
2 1.0
3 1.0

 

Подобные листы согласования помогут Вам в дальнейшем сэкономить рабочее время и прочие затраты. Пока еще ни одного рубля явно не потрачено на проект автоматизации, но Вы потратили свое рабочее время и рабочее время ключевых пользователей - а это тоже деньги. Очень скоро будут потрачены и деньги.

Подведем промежуточный итог. У Вас есть цель и согласованные с целью требования к автоматизации магазина. Это очень хорошее начало проекта. Если без формализованной цели проект еще имеет какие-то шансы на успех, то без требований проект обречен. А наличие цели и требований, да еще и согласованных между собой и участниками проекта дает проекту очень хорошие шансы на успешное завершение.

Теперь Вы готовы осознанно подходить к выбору решения для автоматизации Вашего магазина.

 

3. Выбор

На сегодняшний день на рынке представлено множество тиражных решений для автоматизации розничной торговли в различном ценовом диапазоне, с различным позиционированием. Какие-то решения предназначаются для автоматизации транснациональных торговых компаний и стоят сотни тысяч долларов и выше. Какие-то решения предназначаются для автоматизации небольшого розничного магазина и стоят несколько тысяч рублей.

При таком ассортименте у торгового предприятия практически отпадает необходимость создания решения «под себя» силами собственных специалистов. Большинство решений имеют гибкие средства настройки и позволяют решить большинство торговых задач. Если же этого оказывается недостаточно, существуют системы, которые можно дорабатывать, взяв за основу типовое решение и создав на его основе такое, которое максимально удовлетворяет требованиям конкретного торгового предприятия.

Создавая такие решения, разработчики обобщили опыт создания систем для множества заказчиков, с которыми им приходилось работать. Они создали обобщенную универсальную модель предприятия, которая, по их мнению, подойдет большинству предприятий работающих в той же отрасли.

В данном материале Вы не найдете сравнительных характеристик решений для автоматизации торговли. Во-первых ситуация постоянно меняется, разработчики систем постоянно работают над их улучшением, и такое сравнение придется обновлять чуть ли не ежемесячно. Во-вторых, такое сравнение несколько неэтично, т.к. не бывает абсолютно беспристрастного мнения. Вместо этого будет описана методика, следуя которой Вы сможете выбрать решение, максимально удовлетворяющее Вашим требованиям.

Собственно решение задачи выбора уже заложено в постановке этой задачи. Вам нужно выбрать решение, которое максимально удовлетворяло бы сформированным Вами требованиям и имело бы возможность легкой (или экономичной) настройки и/или доработки для полного их удовлетворения.

Начните анализ с подготовки опросных листов. Сделайте копию документа Требования, и приведите таблицу требований примерно в такой вид:

 

Требования Поддерживается в типовой поставке Реализуется настройками Требует доработок
1
2

 

Теперь Вам необходимо заполнить эту таблицу. Существует несколько способов. Можно, например, разослать электронные письма разработчикам решений с просьбой рассмотреть Ваши требования и ответить, насколько разработанное ими решение подходит для автоматизации Вашего бизнеса. Другой вариант получить демонстрационные версии таких решений и провести анализ самостоятельно.
Но наиболее эффективной будет работа с системными интеграторами в Вашем регионе. Если Вы достаточно заметный игрок на рынке розничной торговли в своем регионе, то информация о том, что Вы заинтересованы в выборе системы автоматизации, скорее всего уже поступила ко всем конкурирующим между собой интеграторам вашего региона. В этом случае Вы уже имеете предложения от них. Если же по каким-то причинам Вы не имеете таких предложений, обратитесь к разработчикам решений, но не с просьбой определить подходит или не подходит Вам их решение, а с просьбой предоставить контакты их региональных партнеров.

Предложите интеграторам заполнить опросный лист. А еще лучше закажите демонстрацию решения и по каждому из пунктов, которые «поддерживаются в основной поставке» требуйте объяснений, как именно Ваше требование реализовано в этом решении. Даже если разные интеграторы предлагают одно и то же решение, анализируйте их отдельно. Вы будете удивлены разной оценкой в опросном листе.

По каждому требованию Вы получите ответ, поддерживается ли оно в основной поставке программного продукта, потребуются ли для его реализации настройки, которые необходимо выполнить специально для Вас, или же потребуется доработка решения под Ваши требования. Если интегратор утверждает, что какое-либо требование не может быть удовлетворено в принципе, то это можно объяснить двумя причинами: либо интегратор предлагает Вам решение, не имеющее возможности доработки, либо Ваше требование невозможно удовлетворить при помощи системы автоматизации.

Как уже было сказано, с требованиями нужно работать на всех этапах проекта. Если ни один из интеграторов не может предложить решение, которое поддерживало бы Ваши требования - это повод пересмотреть требования.

Наиболее распространенные требования, не имеющие поддержки в большинстве существующих на рынке решений для автоматизации розничной торговли, относятся к учету по розничным ценам. Привычные Вам формы отчетов, такие как, например, товарный отчет ТОРГ-29, могут быть не полными или вообще отсутствовать в решениях. Большинство Ваших требований, не получивших поддержки в основной поставке решения, станут не актуальными, если изменить учетную политику с учета по розничным ценам на учет по себестоимости. А требование конфиденциальности информации о закупочных ценах будет иметь иное решение. Ваши работники не узнают закупочных цен, если Вы установите такое требование - распределение прав доступа.

Обратите внимание на требования совместимости с имеющимся у Вас торговым оборудованием. Не исключено, что поддержка имеющегося у Вас оборудования в итоге будет стоить дороже, чем закупка нового, поддерживаемого в стандартной поставке программного обеспечения.

Анализируя предложения рынка решений для автоматизации розничной торговли, Вы можете прийти к выводу, что «нет нормальных систем». Хочется сразу предостеречь Вас от подобного рода выводов. Отрасль розничной торговли не является молодой отраслью и никаких революционных перемен за последнее время в ней не происходило. Решения есть. И большинство решений удовлетворяет большинству требований. В противном случае решений просто не остается на рынке. Если Вы все-таки приходите к такому выводу, скорее всего, Вам следует пересмотреть требования. Если у Вас есть требования, не нашедшие удовлетворения ни в одной из предлагаемых систем, задумайтесь, откуда они взялись. Это может быть отражение ваших «ноу-хау», дающих Вам конкурентные преимущества, а возможно просто-напросто Ваш товаровед так привык работать. Реализация подобных требований «на заказ» удовольствие не дешевое, и подумайте, нужно ли это для реализации ваших стратегических замыслов или для хороших отношений с товароведом.

На этом этапе от Вас не требуется однозначно определить, какое решение Вы выбираете. Проект автоматизации это не только программный продукт и поддерживаемые им бизнес требования, все гораздо сложнее. Выберите 2-3 решения, наиболее полно удовлетворяющие Вашим требованиям своей основной поставкой и имеющим наименьшее количество отметок в графе «Требует доработок».

В доработках как таковых нет ничего плохого. Доработанная функциональность будет работать не хуже, а в некоторых ситуациях даже лучше, чем базовая функциональность. Но, во-первых, доработки требуют времени, а во-вторых, денег. И иногда стоимость подобных доработок превосходит стоимость базового программного обеспечения. Кроме того, существует такое понятие как стоимость владения. А стоимость владения системами с доработанным под конкретный заказ программным обеспечением ощутимо выше, чем стоимость владения аналогичными системами без доработок.

Следующий этап - проведение тендера между системными интеграторами, предоставляющими комплекс услуг по выбранным Вами решениям.

В ходе тендера Вам предстоит выяснить, что именно и по каким ценам предлагают различные системные интеграторы и выбрать наиболее оптимальное предложение.

Подготовьте тендерные запросы системным интеграторам Вашего региона, работающим с выбранными Вами решениями для автоматизации розничной торговли. В запросе опишите рамки планируемого проекта и требования. Запросите технико-коммерческое предложение (ТКП) на лицензии программного обеспечения, оборудование, если оно Вам потребуется, на работы по проекту внедрения и услуги сопровождения. Самое главное, обязательно запросите портфолио интегратора по розничной торговле в Вашем регионе. Нельзя выбирать только по цене предложения. Важно, что бы предложение было подкреплено реальным опытом работы.

Не лишним будет посетить предприятия, на которых интегратор уже выполнил проекты автоматизации и пообщаться с коллегами по бизнесу. У хорошего интегратора, как правило, есть клиент, с которым они имеют договоренность о подобного рода «экскурсиях».

Традиционно в ТКП кроме расчета стоимости проекта описывается, каким образом предлагается удовлетворить требования, описанные Вами в тендерном запросе, приводятся характеристики предлагаемого программного обеспечения и оборудования, дается справка о компании интеграторе и компании разработчике предлагаемого программного обеспечения.

Что бы лучше понять какие именно работы Вам предлагают оплатить в ТКП, рассмотрим основные элементы проектных работ.

Предпроектное обследование - как правило, задача предпроектного обследования это анализ бизнес-процессов и выявление требований. Обследование проводится с целью уточнения состава и объема последующих проектных работ, и само по себе имеет определенную стоимость, которую Вам предлагается оплатить. Этот нюанс может вызвать у Вас справедливое возмущение, особенно если Вы, следуя нашим рекомендациям, собственными силами провели сбор и анализ требований. Интегратор же со своей стороны будет настаивать на том, что у него нет уверенности в полноте собранных Вами требований. Действительно, не редко при детальном рассмотрении требований выявляются дополнительные требования, серьезно влияющие на стоимость проекта. Специалисты, имеющие большой опыт проектных работ с предлагаемым Вам программным обеспечением могут выявить то, что Вы не выявили или не посчитали важным.

Предпроектное обследование похоже на снятие мерок портным, когда Вы заказываете пошив костюма. В принципе можно снять мерки самостоятельно, и портной сошьет по ним костюм. Но вот если костюм будет узок в плечах или слишком коротким, Вы не сможете предъявить претензий портному. Так и любой интегратор, принимает собранные Вами требования за основу, но не может быть уверен в правильности, детальности проработки и полноте собранных Вами требований. Уровень проработки требований у Вас и у интегратора разный. Например, Вам достаточно задать требование, что при неотфактурованной поставке товар должен поступить в торговый зал - таково требование бизнеса. Но интегратору нужно определить массу нюансов: когда и как будут введены данные по поступившей партии товаров, как и когда будет рассчитана себестоимость списанного товара, какие группы пользователей могут выполнять такие операции и т.п.

Подобно портному, интегратор не будет принимать претензий, если Ваш магазин не сможет работать на внедренной системе. «Этого не было в требованиях» нередко будете слышать Вы. Для того, что бы избежать таких ситуаций, лучше не отказываться от этапа предпроектного обследования. Заплатив за него, Вы перенесете ответственность на интегратора.

Формирование технического задания - это основной документ, описывающий систему, которую Вы получите в итоге проекта. В общем случае в техническом задании (ТЗ) описывается:

  • общие сведения;
  • назначение и цели создания системы;
  • характеристика объектов автоматизации;
  • требования к системе;
  • состав и содержание работ по созданию системы;
  • порядок контроля и приемки системы;
  • требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в эксплуатацию;
  • требования к документированию;
  • источники разработки.

ТЗ регламентирует ГОСТ 34.602-89. Однако не рекомендую строго придерживаться этого ГОСТа. Не лишним будет с ним ознакомиться, но для построения системы автоматизации магазина небольшого формата точное следование букве ГОСТа будет излишним, и не сомневайтесь, что эта педантичность будет заложена в бюджет проекта и оплачена Вами. Вполне достаточно, что бы ТЗ соответствовало шаблонам, рекомендуемым разработчиком программного обеспечения, и в нем были описаны наиболее важные разделы. Прежде всего, это требования, состав и содержание работ, порядок контроля и приемки, состав и содержание работ по подготовке объекта к вводу в эксплуатацию.

Установка оборудования. Система автоматизации торговой деятельности магазина, как правило, интегрируется с электронным торговым оборудованием: контрольно-кассовой техникой, электронными весами, принтерами этикеток, терминалами сбора данных и т.п. Установить и настроить оборудование для корректной работы с системой - одна из важнейших задач проекта. Если в рамках проекта Вы закупаете оборудование, его необходимо доставить на Ваши объекты, установить на рабочие места и подключить к локальной сети. Эти работы могут быть включены в стоимость оборудования или выделены отдельно, но они не бесплатны и должны быть заложены в бюджет проекта.

Если оборудование в рамках проекта не закупалось, то в бюджете проекта должна быть заложена настройка существующего оборудования для работы в системе.

Установка программного обеспечения - купив лицензии на программное обеспечение, Вы получаете носитель информации с дистрибутивом актуальной версии и комплектом документации. Следуя инструкциям, Вы можете самостоятельно выполнить установку, можете доверить этот процесс специалистам.

Настройка и/или доработка системы под требования производится специалистами интегратора на основании технического задания.

Тестирование производится специалистами интегратора в присутствии специалистов заказчика по регламенту, описанному в техническом задании.

Обучение пользователей - для того, что бы система работала необходимо обучить пользователей работе с ней. Наиболее оптимальный способ подготовить пользователей это провести обучение на «сквозном» примере. Специалисты интегратора подготавливают пример, в котором задействуют все бизнес-процессы магазина, от заказа товара до подготовки отчетности, обыгрывают различные ситуации, например, возвраты от покупателя, пересортицу, инвентаризацию и т.п. Но существуют и альтернативные способы, например, самостоятельное изучение пользователями технической документации.

Подготовка начальных данных. Для того, что бы начать работать в системе Вам потребуется ввести в нее начальные данные о номенклатуре и ее остатках, о контрагентах, о текущем состоянии взаиморасчетов с ними, о собственных сотрудниках. Существует два способа сделать это: вручную и автоматически.

Второй способ возможен в случае, если эти данные существуют в электронном виде, например в другой системе. Их нужно выгрузить из существующей системы в формат, пригодный для загрузки в новую, нормализовать, т.е. привести в соответствие реляционной модели базы данных** , проверить на соответствие действительности и загрузить в новую систему. Это задача для специалистов по базам данных. Не имея должной подготовки для ее решения вместо оптимизации процесса подготовки начальных данных Вы получите обратный эффект и проблемы на проекте.

Ввод системы в эксплуатацию - обычно под этим подразумевается постоянно присутствие необходимого количества специалистов интегратора на объекте в первые часы или дни эксплуатации системы для решения всех возникающих проблем и затруднений.

Поддержка (синоним Сопровождение) - делится на поддержку программного обеспечения и поддержку конкретной системы, работающей на Вашем объекте. Первая выполняется разработчиками программного обеспечения, может быть бесплатным или платным, второе выполняется интегратором и, как правило, является платной. Поддержка от разработчиков состоит в регулярном получении обновлений программного обеспечения, и возможности обращаться на линию консультаций разработчика. Поддержка от интегратора направлена на обеспечение бесперебойной работы установленной системы и характеризуется временем реакции на обращение. Например, в системе происходит сбой, который Вы не можете устранить собственными силами. Вы обращаетесь к интегратору, оказывающему услуги поддержки и в оговоренное время на объект должен прибыть специалист и устранить возникшую проблему. Все нюансы подобного рода работ регулируются соглашением об уровне сервиса (SLA), которое Вам предложат подписать.
Каждая работа в коммерческом предложении имеет свою стоимость. Если интегратор предлагает Вам какие-либо работы бесплатно, то это всего лишь означает, что их стоимость включена в программное обеспечение, оборудование или другие работы.

Конечно же, разные интеграторы оформляют коммерческие предложения по-разному. Ключевую информацию удобно оформлять в сравнительной таблице:

Критерий  /  Интегратор 1 2 3
1 Удовлетворение требований типовой поставкой программного обеспечения, %
2

Основной программный продукт

Год появления на рынке
Количество проданных лицензий на продукт (пользователей)
Предыдущие программные продукты или версии этого разработчика
Год основания компании разработчика

3 Стоимость предпроектных работ, руб.
4 Сроки проектных работ, месяцев
5 Стоимость проектных работ, руб.
6 Стоимость лицензий на программное обеспечение, руб.
7 Стоимость оборудования, руб.
8 Стоимость годового сопровождения, руб.
9 Время реакции на обращение*** , час
10 Год образования компании
11 Количество успешно выполненных проектов
12 Референс-визит
13 Достоинства
14 Недостатки
15
16

Добавьте в эту таблицу все, что считаете важным и нужным. В таком вопросе как выбор решения для автоматизации не может существовать четкого алгоритма. Многое решается на основании экспертной оценки. Таблица помогает всего лишь наглядно представить информацию, выбор же остается за Вами.

Рекомендуем Вам собрать тендерную комиссию, которая и выберет наиболее подходящий вариант. В подобных вопросах работа в группе оказывается более эффективной, чем принятие индивидуального решения. Но эффективность возможна в группах до 5-и человек, при большем количестве участников эффективность снижается. Для малого бизнеса в тендерную комиссию рекомендуется включить собственников бизнеса и топ-менеджеров, что в большинстве случаев совпадает и редко превышает 5 человек.

Не рекомендую решать вопрос простым голосованием. Голосование допустимо только как крайняя мера. Нужно искать консенсус, обосновывать свой выбор, ссылаясь на полученные результаты и убеждать оппонентов в правильности своего выбора и, разумеется, выслушивать их мнение. Совсем не лишним будет зафиксировать работу тендерной комиссии протоколом заседания, в котором зафиксировать решение, отразить все особые мнения и подписать всеми членами тендерной комиссии.

В данном примере рассмотрен «максимальный» вариант проекта, когда для выполнения работ привлекается ИТ-компания, системный интегратор. Такой вариант не является единственно возможным, Вы можете, например, купить программное обеспечение и оборудование самостоятельно, взять в штат 1-2 специалистов и выполнить все работы собственными силами, или же пригласить фрилансеров - специалистов работающих самостоятельно. Или выбрать компромисс, например, заказать проект автоматизации у ИТ-компании, а для поддержки воспользоваться услугами фрилансера. У этих вариантов есть свои достоинства и недостатки, анализ которых приведен в таблице:

Достоинства Недостатки
Проект с привлечением ИТ-компании интегратора

Высокое качество выполнения работ
Обязательства, скрепленные договорами между юридическими лицами
Сжатые сроки
Поддержка вендоров программного обеспечения и оборудования

Относительно высокая стоимость проектных работ.
Низкая степень влияния на специалистов

 

Выполнение работ силами штатных специалистов Высокая степень влияния на специалистов
Относительно низкая стоимость проектных работ
Возможность менять требования по ходу проекта

Относительно высокая совокупная стоимость владения системой 
Невозможность на начальных этапах определить стоимость проекта
Растянутые сроки

Услуги фрилансеров Низкая совокупная стоимость Высокие риски
Отсутствие каких-либо юридических гарантий

Однозначного ответа на вопрос «что выбрать» не существует. Анализируйте, оценивайте риски, не забывайте, что многое зависит и от личных отношений.

В любом случае, ни при каких обстоятельствах не делайте выбор в пользу нелицензионного программного обеспечения. Использование нелицензионного программного обеспечения является формой воровства. Вам не приятно, когда у Вас воруют товар. Хоть в бюджете и заложен процент на кражи, Вы, тем не менее, по всей строгости закона разберетесь с пойманным за руку вором. Точно так же себя ведут и правообладатели программного обеспечения. Рассмотрев бюджет проекта, Вы поймете, что он не только и не столько состоит из стоимости лицензий, однако риски, которые влечет за собой использование нелицензионного программного обеспечения стоят гораздо больше.

Итак, выбор сделан. Зафиксируйте его в Уставе проекта. Добавьте в раздел «Участники проекта» команду от интегратора (собственных специалистов или выбранного «фрилансера»). Создайте новый раздел «Архитектура» и опишите в нем то, что предлагается в принятом коммерческом предложении. Уточните временные рамки проекта. Присвойте Уставу проекта очередной номер версии и подпишите лист согласования всеми участниками проекта.

Количество проектных документов и их версий растет, и уже у Вас имеется:

  1. Устав проекта;
  2. Требования;
  3. Тендерный запрос;
  4. Коммерческие предложения;
  5. Протокол заседания тендерной комиссии.

В дальнейшем состав документов будет расти, существующие документы будут обновляться. Вам следует задуматься о хранении проектных документов.

Рекомендую хранить бумажные и электронные версии документов. Распечатывайте каждую согласованную версию документа и подшивайте ее в папку проекта вместе с листом согласования. В ходе проекта Вы неоднократно будете встречаться с другими участниками и обсуждать различные вопросы, Вам будет удобнее работать с папкой документов, чем с набором файлов.

Создайте на сервере или на любом постоянно доступном диске Вашей локальной сети папку, сделайте ее доступной всем участникам проекта, и храните в ней все проектные документы. Не забывайте периодически их архивировать. Например, еженедельно копируйте содержимое папки на CD-RW диск и уносите его домой.

Теперь Вы готовы осознанно подойти к планированию бюджета проекта.

 

4. План и бюджет

В управлении проектами понятия план и бюджет неразрывно связаны между собой. Бюджет проекта напрямую зависит от состава и срока работ и ресурсов, необходимых для их выполнения.

Вы уже встречали и план, и бюджет в коммерческих предложениях. Но указанные там план и бюджет не являются полными, поскольку они относятся только к той части проекта, в которой участвует конкретный подрядчик, и касаются только его зоны ответственности. Общий план и бюджет проекта будет также включать Ваши собственные затраты рабочего времени, затраты Вашего персонала на подготовку инфраструктуры, внос необходимых данных в систему и т.п. И эти затраты также необходимо учитывать в плане и бюджете проекта

В идеальной ситуации перед началом проекта нужно создать план, сформировать бюджет и приступить к исполнению плана и освоению бюджета. Но в действительности невозможно этого сделать перед началом проекта. Это можно сделать, только выполнив часть проектных работ, таких как сбор и анализ требований. Это обычная практика, когда само планирование входит как одна из работ в план.

Для формирования плана воспользуемся классической методикой сетевого планирования. Суть методики состоит в том, что необходимо определить перечень работ, определить их трудоемкость, выстроить их логическую взаимосвязь во времени (календарное планирование) и определить ресурсы, необходимые для выполнения работ (ресурсное планирование).

Начнем с восстановления информации о фактически проделанной работе с даты начала проекта. Было выполнено следующее:

1. Инициализация проекта, результатом которой явилось решение о начале проекта и формализация цели проекта;
2. Сбор и анализ требований, с соответствующим документом в итоге;
3. Подготовка и проведение тендера по выбору решения и подрядчика

Примерно восстановите хронологию этих работ и все затраты, связанные с их проведением. Затраты прежде всего состоят из рабочего времени, Вашего собственного, ключевых пользователей, и членов тендерной комиссии.

Существуют различные программные продукты, для создания планов и контроля их исполнения. Если Вы владеете каким-либо из подобных продуктов, можете им воспользоваться для решения задачи планирования. Это удобно, но вовсе не является обязательным условием успешности проекта. Гораздо важнее содержание, а удобную форму, например, диаграмму Ганта, можно сделать практически в любом графическом пакете. Для проекта подобного масштаба это более чем достаточно.

Откройте табличный редактор, создайте в нем новый документ и назовите его «План проекта».

Отразите в нем выполненную на текущий момент работу примерно в таком формате:

 

Работа Дата начала Длительность Дата завершения %% выполнения
1 Инициализация проекта ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 100
2 Первичный сбор и анализ требований ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 100
3 Подготовка и проведение тендера ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 100
4 Выбор подрядчика ХХ.ХХ.ХХ 100
5 Планирование проекта ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 50
6 План проекта ХХ.ХХ.ХХ 0
7 Предпроектное обследование ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
8 Формирование  ТЗ ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
9 Техническое задание ХХ.ХХ.ХХ 0
10 Подготовка рабочих мест ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
11 Установка оборудования ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
12 Установка оборудования ХХ.ХХ.ХХ 0
13 Установка ПО ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
14 Установка программного обеспечения ХХ.ХХ.ХХ 0
15 Настройка системы ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
16 Тестирование ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
17 Обучение пользователей ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
18 Завершение обучения пользователей ХХ.ХХ.ХХ 0
19 Запрос электронных каталогов у поставщиков ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
20 Инвентаризация ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
21 Подготовка и загрузка начальных данных ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
22 Подготовка начальных данных ХХ.ХХ.ХХ 0
23 Фискализация кассовых аппаратов ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
24 Запуск в эксплуатацию ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0
25 Начало промышленной эксплуатации ХХ.ХХ.ХХ 0
26 Сопровождение ХХ.ХХ.ХХ XX ХХ.ХХ.ХХ 0

 

В Microsoft Project это может выглядеть так:

Включите в план работы из принятого коммерческого предложения, в таблице отмечено курсивом. Кроме работ, явно указанных в коммерческом предложении будут работы, которые Вам необходимо сделать перед тем, как подрядчик выполнит свои работы. В приведенной выше таблице они отмечены подчеркиванием. Так, например, перед установкой оборудования Вам необходимо подготовить рабочие места, а перед запуском в эксплуатацию Вам необходимо фискализовать новую кассовую технику. Полностью перечень таких работ будет определен в техническом задании, возможно, с учетом их объема и содержания, Вам потребуется корректировка плана.

Добавьте после ввода системы в эксплуатацию несколько дней сопровождения с обязательным присутствием на ваших объектах специалиста исполнителя. Эти работы можно считать как проектными, так и отнести их к сопровождению. В любом случае в первые дни эксплуатации системы Вам потребуется присутствие специалистов для решения возникающих вопросов по работе с системой и устранения возможных сбоев.

При планировании следует помнить, что план - не догма, а средство управления проектом. В ходе проекта в план будут постоянно вноситься какие-то корректировки и уточнения. Лучше плохой план, чем никакого. Если Вы на начальном этапе не можете определить, сколько потребуется дней и ресурсов для подготовки рабочих мест, запланируйте приблизительно, так как Вы себе представляете эти работы. По мере приближения к плановой дате начала этих работ план можно будет уточнить. Но если по причине того, что Вы не можете дать точной оценки той или иной работе она не попадет в план, это будет куда более серьезная ошибка, чем ошибка в оценке срока работ. Вы рискуете вспомнить о необходимости выполнения такой работы слишком поздно, когда она уже должна быть выполнена, а без результатов этой работы невозможно приступить к выполнению другой работы.

Выделите работы, приносящие важнейшие результаты как ключевые вехи, в данной таблице они отмечены жирным цветом. Это общие для большинства проектов вехи, такие как «Выбор подрядчика», «Техническое задание», «Начало промышленной эксплуатации», и специфические для проекта автоматизации розничного магазина вехи, такие как «Установка программного обеспечения» «Установка оборудования», «Завершение обучения пользователей», «Подготовка начальных данных». Каждая веха - это промежуточный результат проекта, который можно проконтролировать, и по своевременному его достижению и соответствию ожиданиям получить представление о состоянии проекта в целом.

После того, как Вы добавили в план все работы, оценили их длительность и установили взаимосвязь между ними, проанализируйте план методом критического пути. Суть этого метода в том, что любая работа в плане должна приближать Вас к какой либо вехе, т.е. давать какой-либо важный для цели проекта результат. Если работа никак не влияет на достижение цели проекта, ее следует исключить из плана.

Не следует излишне усложнять план. Детализируйте работы ровно до такой степени, которой будет Вам достаточно для дальнейшего управления ими. Любую работу можно детализировать вплоть до отдельных операций для каждого специалиста. Но нужно ли? Оптимальной считается такая детализация работ, с которой руководитель проекта будет ставить задачи членам проектной группы и контролировать результат их работы.

Ресурсное планирование состоит в определении для каждой из работ ресурсов, необходимых для ее выполнения. К таким ресурсам относятся рабочее время членов проектной команды, денежные средства, материалы и т.п.

Бюджет лучше вести в отдельном от рабочего плана проекта документе. Дело в том, что в проекте есть участники, которым для эффективной работы нужно знание плана проекта, но бюджет проекта им знать ни к чему. Создайте в табличном редакторе новый документ и назовите его «Бюджет проекта».

Перед тем как приступить к оформлению бюджета, необходимо определить статьи бюджета. Для оформления бюджета используйте таблицу примерно такого формата, в ней же определены типичные для проекта автоматизации магазина статьи:

Статья Сумма январь февраль
1 Зарплата персонала
2 Услуги подрядчика
3 Закупка оборудования
4 Закупка лицензий на программное обеспечение
5 Услуги сторонних организаций
6 Недополученная прибыль
7 Прочее
8 Резерв
9

ИТОГО

В данном примере бюджет детализируется по статьям затрат и месяцам. Предполагается, что проект начинается в январе и заканчивается в феврале, соответственно выплаты по проекту будут в двух месяцах.

Теперь рассмотрим способы оценки бюджета проекта по статьям затрат.

Зарплата персонала. В плане проекта по каждой из работ, составьте список сотрудников, которые будут в них участвовать, и определите для каждого из них коэффициент участия. Если сотрудник задействован полностью на выполнение работы.

Умножьте дневную зарплату сотрудника на продолжительность работы в днях и коэффициент участия. Просуммируйте по всем сотрудникам, участвующим в выполнении работы. В зависимости от плановых сроков выполнения работ эти суммы будут распределяться по месяцам в бюджете проекта.
Типична такая картина занятости в розничном магазине:

 

Работа Ресурсы Занятость
1 Инициализация проекта Директор 100%
2 Первичный сбор и анализ требований Директор 30%
IT-Служба 50%
Ключевые пользователи 20%
3 Подготовка и проведение тендера Директор 30%
IT-Служба 50%
4 Планирование проекта Руководитель проекта 100%
5 Предпроектное обследование Руководитель проекта 80%
Ключевые пользователи 20%
6 Формирование ТЗ Руководитель проекта 50%
7 Подготовка рабочих мест IT-Служба 100%
8 Установка оборудования IT-Служба 100%
9 Установка ПО IT-Служба 100%
10 Настройка системы IT-Служба 100%
11 Тестирование Руководитель проекта 100%
IT-Служба 100%
12 Обучение пользователей Все пользователи 30%
13 Запрос электронных каталогов у поставщиков IT-Служба 100%
Категорийные менеджеры / менеджеры закупок 100%
14 Инвентаризация Категорийные менеджеры / товароведы, кладовщики 100%
15 Подготовка и загрузка начальных данных IT-Служба 100%
16 Фискализация кассовых аппаратов Главный бухгалтер 50%
17 Запуск в эксплуатацию Все 100%
18 Сопровождение IT-Служба 100%

 

Если какой либо участник равномерно занят в проекте на протяжении всей его длительности, то затраты на него можно посчитать по упрощенной схеме. Например, Вы знаете, что как руководитель Вы участвуете во всех работах проекта, и параллельно занимаетесь текущей работой магазина. Отнесите 50% своих затрат на всю длительность проекта, не детализируя это по отдельным работам.

Услуги подрядчика. В коммерческом предложении есть разделы стоимость работ, выполняемых подрядчиком и/или график платежей. Это и есть статья затрат.

Закупка оборудования. Оборудование для проекта может закупаться у выбранного интегратора, у сторонней организации или не закупаться вовсе. Если эта статья затрат не нулевая, у Вас имеется коммерческое предложение по оборудованию. Проставьте соответствующие значения в данную статью бюджета.

Закупка лицензий на программное обеспечение. Аналогичным образом значение берется из соответствующего раздела коммерческого предложения.

Услуги сторонних организаций. К ним относятся затраты связанные с проектом, но по каким-либо причинам оплачиваемые сторонним организациям, не участвующим в проекте. Например, это может быть фискализация кассовой техники, ремонтные работы в помещениях, где оборудуются рабочие места и т.п.

Недополученная прибыль. Если в плане проекта будет остановка торгового процесса, то Вы несете убытки в виде недополученной прибыли. Умножьте плановую дневную прибыль магазина на плановое количество дней простоя и внесите полученную цифру в соответствующую графу бюджета.

Это далеко не полный и не единственно возможный перечень статей затрат. Если Вы видите еще возможные статьи затрат, но их значение невелико, можно учитывать их в статье Прочее.
В завершении верстки первой версии бюджета добавьте 5-10% в качестве резерва. Даже идеально составленный бюджет в начале проекта, как правило, приходится увеличивать в ходе проекта примерно на это значение.

В этом материале рассматривается классический подход к ведению проекта, часто называемый «каскадная модель». План работ на диаграмме Ганта напоминает каскад водопадов - отсюда и такое название. Такой подход дает однозначное понимание требуемых сроков и ресурсов, необходимых для выполнения проекта. Соответствие плана и факта во многом зависит от того, насколько четко ставятся задачи членам проектной команды и контроля выполнения этих задач.

После составления плана проекта нужно довести его до сведения всех участников проекта, что бы каждый четко понимал свои задачи. Бюджет проекта обязательно согласуйте с собственниками и топ-менеджерами. Запланируйте необходимые платежи по проекту.

В таком краткосрочном проекте как автоматизация магазина нет необходимости отдельно планировать коммуникации. Тем не менее, коммуникации в проекте имеют большое значение, и какой-то минимум действий по их планированию нужно предусмотреть. Обычно для краткосрочных проектов, к которым относится проект автоматизации магазина, применяется такой набор:

 

Источник Получатель Сообщение Периодичность
1 Руководитель проекта Вся команда Установочное собрание.Цели проекта, план проекта, определение ролей участников В начале проекта
2 Подрядчик Руководитель проекта Отчет о предпроектном обследовании Однократно, в соответствии с планом
3 Вся команда Руководитель проекта Отчет о выполненных работах Еженедельно
4 Руководитель проекта Вся команда Установочное собрание перед началом эксплуатации. Уточнение плана действий, определение ролей участников Однократно, в соответствии с планом
5 Руководитель Вся команда Итоговое собрание. Принятие результатов проекта. Закрытие проекта. Однократно в конце проекта

 

Для предотвращения различного рода неприятных сюрпризов, возникающих в ходе проекта, служит процесс управление рисками. Риском называется вероятное событие, осуществление которого может поставить под угрозу цели, рамки, план или бюджет проекта. Управление рисками состоит в их идентификации, принятии той или иной стратегии работы с рисками и регулярном мониторинге рисков.

В подобного рода краткосрочных проектах основной риск, который существует - несвоевременная поставка необходимых ресурсов для выполнения проектных работ. Например, задержка с поставкой оборудования поставит своевременное выполнение проекта под угрозу.

Существует три основных стратегии работы с рисками: уклонение, принятие и делегирование. Уклонение от риска предполагает изменение плана проекта таким образом, что бы осуществление риска не повлияло на параметры проекта. Принятие риска обозначает, что мы допускаем возможность возникновение риска и планируем действия по минимизации вероятности его возникновения и его возможного негативного влияния на проект. Делегирование риска предполагает перекладывание ответственности за негативное влияние осуществленного риска на внешнюю сторону, например, страхование риска.

В рассматриваемом примере для уклонения от риска «срыв поставки оборудования» можно выбрать стратегию уклонения и перенести соответствующий этап на более ранний срок, или делегирование, и предусмотреть штрафные санкции в договоре на поставку оборудования.

В краткосрочных проектах, как правило, нет возможности организовать полноценный процесс управления рисками. Собственно для такого масштаба проекта наиболее оптимальным будет идентификация рисков на этапе планирования проекта и уклонение от большинства выявленных рисков. Для прочих рисков, по которым выбирается стратегия минимизации или делегирования разрабатываются альтернативные планы проекта, вступающие в силу в случае осуществления риска.

План управления рисками можно оформить в виде таблицы:

 

Риск Стратегия Вероятность Мероприятия
1 Срыв графика поставки оборудования Делегирование 10% Штрафные санкции по договору
2
3

 

Выполнение плана нужно контролировать регулярно. Для большинства проектов такого масштаба оптимальным является недельный цикл контроля. По мере приближения к ключевым вехам проекта применяется однодневный цикл контроля.

Каждый такой цикл завершается оценкой выполненного объема работ и, если это потребуется, пересмотром плана. Еженедельно (или по требованию), исполнители должны предоставлять Вам отчет о фактически выполненных работах с оценкой выполненного объема от 0 до 100% запланированной работы. Сопоставляя календарный план с достигнутыми результатами можно на ранних этапах выявить проблемы и пересмотреть план, добавив ресурсы на выполнение проблемных задач или пересмотреть сроки их выполнения.

Пренебрежение и откладывание решения проблем с отставанием от плана чревато серьезными последствиями. Дело в том, что при накоплении отставания Ваш план теряет свою актуальность, а т.к. в проекте, как правило, задействовано несколько участников, возникает несогласованность между их действиями. Например, Вы запланировали инвентаризацию, но к запланированной дате настройка системы не завершена, и данные инвентаризации невозможно будет ввести в систему. Эти данные утратят свою актуальность, и к моменту готовности системы Вам потребуется повторно провести инвентаризацию.

В Вашем проекте появилось еще два важных документа - план и бюджет проекта. Сверьте план проекта с временными рамками, описанными в Уставе проекта. Если ключевые даты не совпадают, приведите их в соответствие. Не забывайте согласовывать с участниками проекта новые версии существующих проектных документов.
Теперь Вы имеете полное представление о том, что желаете получить и каким именно образом этого добиться. Остается только выполнить план в указанные сроки и в рамках согласованного бюджета. Если не терять контроль над проектом то это возможно.

 

5. Управление договорами

В рамках проекта запланировано приобретение оборудования, программного обеспечения и оказание комплекса услуг. Соответственно Вам будет предложено три разных договора, даже в том случае, если и оборудование и программное обеспечение и услуги будут предоставлены одним и тем же поставщиком.

Все договора будут предоставлены Вам интегратором и по согласованию в них можно вносить правки. Интеграторы не первый день работающие на рынке имеют типовые шаблоны договоров, удовлетворяющие большинство их клиентов. Кроме того, создатели программных продуктов, целенаправленно развивающие свою партнерскую сеть, такие как фирма «1С», оказывают своим партнерам методологическую поддержку и предоставляют типовые формы договоров для поставки программных продуктов и предоставлению услуг. Эти договора прошли согласования с юристами множества компаний и не вызвали у них нареканий.

Далее будут кратко рассмотрены юридические аспекты договорных отношений в проекте автоматизации магазина.

Для поставки оборудования в соответствии со статьей 454 Гражданского кодекса РФ (ГК РФ) требуется заключение договора купли-подажи.

Вы не раз заключали подобные договора, и, конечно же, знакомы с их формой и содержанием. Обратите особое внимание на график поставки. Оборудование должно быть на Ваших объектах до начала работ с ним.

Крайне желательно, что бы договор предусматривал тестирование оборудования у поставщика перед тем, как оно отправится к Вам. Если этого не сделать, и оборудование окажется бракованным, то Вы будете вынуждены отправлять оборудование обратно и ждать новой поставки. При этом в соответствии с договором, поставщик будет обязан или поставить Вам новое оборудование или починить уже поставленное, соответственно штрафных санкций к нему применить Вы не сможете. А поскольку проекты автоматизации розничных магазинов, как правило, очень быстротечны, сбой в поставке оборудования повлечет за собой срыв сроков проекта в целом и дополнительные финансовые убытки в случае простоя.

Для поставки программного обеспечения в соответствии со статьями 1235 и 1236 ГК РФ требуется заключение лицензионного договора, предметом которого является передача простой неисключительной лицензии на использование программного обеспечения.

Исключительное право на программный продукт остается за правообладателем, на основании этого права он за вознаграждение предоставляет право использования (простую неисключительную лицензию) Вам. Интегратор, который является региональным партнером правообладателя, имеет с ним подобный лицензионный договор, в котором ему предоставляется право приобретать лицензии у правообладателя по одной цене и передавать их пользователям, т.е. Вам по другой.

Ваши права пользователя, обладающего простой неисключительной лицензией, оговариваются в лицензионном (пользовательском) соглашении. Такое соглашение поставляется вместе с носителями программного продукта в печатном или электронном виде. Лицензионное соглашение строится в виде договора оферты между правообладателем программного продукта и пользователем. Принимая условия лицензионного соглашения в соответствии со статьей 435 ГК РФ, Вы связываете себя договорными отношениями с правообладателем программного продукта. Дальнейшая эксплуатация программных продуктов для автоматизации Вашего магазина регулируется именно этим лицензионным соглашением.

Для того чтобы привлечь в проект внешнего исполнителя для оказания услуг, в соответствии со статьей 779 ГК РФ Вам требуется заключение договора возмездного оказания услуг. Другой вариант привлечения в проект интегратора, в соответствии со статьей 702 ГК РФ - заключение договора подряда.

Оба вида договора подходят для оформления обязательств в проектах автоматизации магазина. По договору возмездного оказания услуг исполнитель обязуется оказать услуги в соответствии с перечнем услуг, созданном на основе плана проекта и в указанные сроки. А по договору подряда подрядчик обязуется выполнить работы по заданию, так же сделанному на основании плана проекта.

Обратите внимание, что если у исполнителя (подрядчика) нет лицензии на образовательную деятельность, то в перечне услуг (составе работ) не будет обучения пользователей. Вместо этого исполнитель (подрядчик) укажет консультационные услуги (подготовку пользователей к работе в системе). Ничего криминального в такой формулировке нет. Для обучения пользователей работе в системе профессиональные преподаватели не нужны, вполне достаточно специалистов, разбирающихся в программном продукте и бизнес-процессах розничного предприятия.

Скорее всего, интегратор предложит Вам заключить договор возмездного оказания услуг. В большинстве случаев такого договора достаточно. Однако если у вас имеются какие-либо ноу-хау, для автоматизации которых Вы хотите создать программы для ЭВМ и/или базы данных, и в дальнейшем распоряжаться ими, то такого договора может оказаться недостаточно. Дето в том, что по договору возмездного оказания услуг не предполагается создания какой либо интеллектуальной собственности. Если, выполняя услуги по такому договору, исполнитель создает интеллектуальную собственность (программу для ЭВМ, базу данных), то в соответствии со статьей 1228 ГК РФ у него возникает исключительное право на результат интеллектуальной деятельности, которым он вправе распоряжаться по своему усмотрению в соответствии со статьей 1229 ГК РФ. Вы получите оплаченные услуги, а интегратор, пользуясь созданными им в рамках проекта программами для ЭВМ и базами данных, может создать тиражируемый программный продукт и получать доход от его распространения, не выплачивая Вам никаких дивидендов. Если для Вас это принципиально, заключите договор подряда. Предметом этого договора среди прочего укажите создание программы для ЭВМ и/или базы данных, и передачу Вам исключительных прав на них.

Взвесьте все за и против. Готовы ли Вы стать правообладателем такой интеллектуальной собственности? Это повлечет для Вас дополнительные затраты и не является Вашей основной деятельностью. Наиболее распространенная ситуация, когда обладание правами на интеллектуальную собственность для Вас может быть обоснованно - автоматизация магазина франчайзи какой-либо большой сети. Например, Вы являетесь таким франчайзи и решили внедрить у себя некий программный продукт. В результате проекта Вы планируете получить конфигурацию, полностью удовлетворяющую потребностям Вашего и большинства других магазинов франчайзи. Если Вы считаете, что это заинтересует ваших коллег по сети франчайзи - игра стоит свеч. И не сомневайтесь, что интегратор думает так же - это предмет для взаимовыгодного сотрудничества.

Не спешите отдавать подписанные договора бухгалтеру. Сделайте копию, и подшейте в папке проекта, в проектных работах не раз придется вспоминать и напоминать подрядчику условия договоров.

 

6. Контроль исполнения

Вернемся снова к плану проекта. Теперь, когда проект можно начинать, необходимо обеспечить контроль исполнения плана.

Для контроля хода проекта автоматизации любого предприятия со стороны заказчика, т.е. с Вашей стороны, используется методика освоенного объема. Выполнение каждой задачи оценивается в процентах от запланированного объема работ. Каждый исполнитель для отчета оценивает текущее состояние порученных ему работ.

Например, в соответствии с планом Ваш системный администратор должен установить 1 сервер, 5 рабочих станций и 1 сетевой принтер. В плане это зафиксировано единой задачей длительностью в 5 рабочих дней. Отчет формируется на 4-й день выполнения этой задачи. Системный администратор установил только 1 сервер и оценивает выполнение работы на 80% - такова его экспертная оценка отношения фактически выполненной работы, что вполне укладывается в план проекта.

На основании оценки отдельных работ в плане строится общая оценка выполнения проекта. Специализированное программное обеспечение для управления проектами, такое как, например, Microsoft Project автоматически рассчитывает эту оценку. Самостоятельно можно ее рассчитать как отношение плановых «человеко-дней» (длительности работ, умноженной на количество исполнителей и коэффициент участия каждого исполнителя) к аналогичному показателю по фактически выполненным работам проекта.

Проект считается выполненным тогда, когда выполнены 100% запланированных в нем работ.

На практике методика реализуется следующим образом:

  • Вы определяете процедуры контроля проекта и согласуете их с исполнителем;
  • Для рассматриваемого примера скоротечного проекта оптимальным будет такой набор:
    • 1 раз в неделю совещание руководителей проекта со стороны заказчика и исполнителя. Допускается совещание по телефону.
    • 2 раза в неделю руководитель проекта со стороны исполнителя направляет руководителю проекта со стороны заказчика актуализированный план, с указанием фактически освоенного объема

Процедуры информирования, описанные выше, в упрощенном виде называются планом коммуникаций проекта. Рассматриваемом нами проекте сейчас всего два участника, и формализовать его в виде отдельного проектного документа практического смысла нет. Однако имейте в виду, что при добавлении в проектные коммуникации большего числа участников Вам может потребоваться формализация плана коммуникаций.

В тот момент, когда начинаются первые работы проекта, первоначальный план теряет свою актуальность. Во-первых, появляется освоенный объем, 0% выполнения работы сменяются другим значением, отражающим прогресс выполнения работы. А во-вторых, как мы говорили выше, идеального плана не существует, и фактическое состояние дел всегда будет чем-то отличаться от запланированного. Нам же нужно как можно раньше выявить эти отклонения, что бы скорректировать другие проектные работы.

Именно актуальное состояние плана проекта будет постоянной повесткой на совещании руководителей проекта. Она выглядит примерно так:

  1. Отчет о ходе проекта.
  2. Принятие отдельных этапов проектных работ.
  3. Согласование изменений плана проекта.
  4. Прочие вопросы.

В ходе таких регулярных совещаний Вы сможете понять причины, повлиявшие на ход выполнения проекта, проанализировать риски проекта и оценить достигнутые результаты.

Исполнитель, как правило, закладывает в договора оплату отдельных этапов проектных работ по факту их сдачи. На таких совещаниях так же можно проводить подписание актов об оказании услуг, закрывающих соответствующий этап договора.

Для контроля за ходом выполнения проектных работ исполнитель может использовать собственную методику, собирать подписи на промежуточных актах и формулярах. Например, по факту установки оборудования подписать с Вашим системным администратором акт ввода в эксплуатацию оборудования, по результатам обучения персонала подписать акт об оказании услуг по обучению. Эти документы должны быть представлены Вам на регулярных совещаниях и помогут избежать недоразумений.

Кроме того, исполнитель может так же вести листы учета рабочего времени, и требовать их подписания ответственным сотрудником с Вашей стороны. Во-первых, такой контроль требуется исполнителю для управления собственными ресурсами, а во-вторых, в случае возникновения конфликтной ситуации между Вами и исполнителем, при рассмотрении дела в арбитражном суде листы учета рабочего времени будут служить основанием для принятия решения об объеме фактически оказанных исполнителем услуг.

Если предыдущие разделы управления проектом Вами проработаны достаточно тщательно, то контроль исполнения проекта не принесет Вам неожиданных сюрпризов. Но для того, чтобы Вы были заранее готовы к возможным неожиданностям, рассмотрим наиболее частые случаи возможных недоразумений:

1. Исполнитель сообщает о том, что не успеет выполнить работу к запланированной дате. Это собственно «запланированная неожиданность». Вряд ли Ваш проект обойдется без нее. Что бы точно знать, сколько времени займет выполнение той или иной работы, нужно ее выполнить. При составлении плана работ можно оценить, сколько времени приблизительно занимает эта работа. Погрешность зависит от опыта руководителя проекта на аналогичных проектах. Кроме неточности планирования влияние на сроки проекта оказывает человеческий фактор, специалист исполнителя может, например, заболеть, или уволиться. Причиной может быть и взаимодействие с Вашими сотрудниками. Кто-то вовремя не предоставил ту информацию, которая от него требовалась, не ознакомился с документом и не подписал его, в результате чего специалист исполнителя отказался делать работу по несогласованному заданию. Или же Ваш сотрудник наделал ошибок при ручном вводе начальных данных в установленную информационную систему, что часто бывает, даже не смотря на пройденное обучение.

Регулярный мониторинг результатов на промежуточных этапах проекта, проведение рабочих совещаний с исполнителем позволит Вам вовремя получить информацию о возникших сбоях и принять соответствующие меры.

Но причина сбоя в сроках может быть и не столь очевидной для Вас. Дело в том, что большинство интеграторов работают с так называемой матричной системой управления персоналом в проектах. Это означает, что каждый специалист работает более чем на одном проекте одновременно, и по мере необходимости переключается между ними. Если у исполнителя возникают непредвиденные проблемы на проекте, который для него более приоритетен, чем Ваш, он перебрасывает на него свои ресурсы. Чтобы этого избежать, необходимо тщательно прорабатывать в договоре ответственность исполнителя за срыв сроков работ.

2. По результатам этапа «Формирование технического задания» исполнитель настаивает на существенном увеличении бюджета и сроков проекта. Такая ситуация возможна, если в ходе работы над техническим заданием были выявлены обстоятельства которые не удалось выявить на этапах формирования требований и предпроектного обследования. Проанализируйте эти обстоятельства, вернее требования с ними связанные. Возможно два основных источника их появления:

  1. В процессе работы над техническим заданием у Вас возникли дополнительные требования, которые не были обозначены на предыдущих этапах.
  2. Реализация какого либо из Ваших требований была неправильно оценена на предыдущих этапах, не учтены все нюансы и взаимосвязи.

В первом случае причиной увеличения бюджета и сроков всецело являетесь Вы или Ваши сотрудники. Проанализируйте, насколько действительно обоснованы эти дополнительные требования. Можно ли обойтись без них, можно ли реализовать эти требования после завершения проекта, в рамках сопровождения и развития Вашей системы.

Во втором случае все не так однозначно. Опытный интегратор, выполнивший множество подобных проектов так не ошибается. Если требование оценено как поддерживаемое в типовом продукте, а в ходе проекта выясняется, что для удовлетворения этого требования требуются доработки - это однозначно свидетельствует о недостаточном профессионализме специалистов исполнителя. Не исключены и манипуляции со стороны исполнителя. Что бы выиграть тендер он может сознательно занижать стоимость коммерческого предложения, в надежде поднять ее на требуемый уровень в ходе проекта. Рекомендации, полученные со стороны других заказчиков, позволят Вам избежать подобных ситуаций и выбрать того исполнителя, который обладает соответствующим опытом и умеет объективно подходить к оценке работ.

3. Исполнитель сообщает, что интегрировать Ваше торговое оборудование в систему не представляется возможным в рамках бюджета проекта, и предлагает Вам приобрести другое оборудование или увеличить бюджет проекта.Такая ситуация возможна при использовании оборудования, о котором разработчик системы автоматизации не сообщает как о поддерживаемом в его информационной системе. Многие разработчики сертифицируют оборудование на совместимость со своими системами - лучше использовать именно такое сертифицированное оборудование. Если же у Вас такого оборудования нет, и Вы не готовы инвестировать в новое, то такой сюрприз для Вас вполне вероятен, особенно, если выбранный Вами исполнитель никогда не имел дело с таким оборудованием, а «где-то читал», что его можно подключить.

4. Исполнитель сообщает, что предоставленные Вами исходные данные по товарной номенклатуре не годятся для ввода в систему в качестве начальных данных, и требует или ввода данных вручную Вашими силами или увеличения бюджета и сроков проекта для приведения данных в надлежащий вид. Это весьма распространенная ситуация. Ни один исполнитель не в состоянии точно определить трудоемкость экспорта начальных данных из произвольного источника, не проанализировав его. При формировании коммерческого предложения на этот этап закладывается некое среднее временное значение, аналогичное «средней температуре по больнице». На этапе предпроектного обследования и формирования технического задания уточняется, откуда именно будут экспортироваться данные, проверяется возможность прочитать данные из источника, качество же самих данных как следует не проверяется. И вплотную к анализу данных специалисты подходят только в рамках выполнения соответствующей работы. Потратив время и ресурсы на более тщательное предпроектное обследование, включающее в себя анализ качества исходных данных, Вы сможете снизить данный риск.

НАВЕРХ

7. Закрытие проекта

Проект считается выполненным, когда выполнены все запланированные в нем работы, пройдены все вехи, достигнуты поставленные цели.

Хорошо составленный план, проанализированный по критическому пути, устроен так, что достижение последней вехи проекта возможно только при достижении всех промежуточных вех и выполнения всех запланированных работ.

Когда Вы достигните финишной черты проекта - итоговой вехи, проект будет выполнен на 100%.

Если в ходе проекта Вы держали руку на пульсе, контролировали ход выполнения проекта, то достижение финиша не будет для Вас неожиданностью, как и тот результат, с которым Вы выходите к финишу.

Итак, с чем же Вы пришли к завершению проекта:

  1. Вы стали обладателем простой неисключительной лицензии на один или несколько программных продуктов, составляющих основу Вашей информационной системы.
  2. На базе Вашей информационно-технической инфраструктуры инсталлирована и настроена (доработана) под Ваши требования система автоматизации магазина.
  3. В этой системе обрабатываются данные, отражающие реальное состояние дел Вашего бизнеса.
  4. Ваш персонал и Вы обучены работе в системе.
  5. Вы можете в любой момент войти в систему и проконтролировать состояние Ваших дел
  6. У Вас на руках имеется полный набор проектной и технической документации, детально описывающей, что же из себя представляет Ваша система автоматизации магазина.

Можно подписать последний акт к договору об оказании услуг с интегратором, оплатить последний счет, тем самым закрыв договор с ним.

Для достижения поставленной цели остается один шаг, и обязательно нужно его сделать. Необходимо запустить систему в промышленную эксплуатацию - издать приказ о начале промышленной эксплуатации и с назначенной даты вести все хозяйственные операции магазина в новой системе. Только когда в ней заработают пользователи и будут отражать реальное состояние дел, Вы достигните поставленной цели - получите контроль над Вашим бизнесом.

Процесс управления проектом внедрения информационной системы управления магазином на этом можно считать успешно завершенным. И начинать новый проект - проект ее сопровождения и развития. Жизнь не стоит на месте, бизнес развивается, предъявляет новые требования к средствам автоматизации. Эти требования будут через новые проекты превращаться в новые возможности Вашей информационной системы. Вам нужно будет принимать решение о целесообразности таких проектов, анализировать их эффективность, контролировать совокупную стоимость владения системой. Надеемся, что опыт, полученный Вами в процессе проекта автоматизации Вашего магазина, поможет Вам решать новые задачи более успешно и с меньшими усилиями.

* First Expired First Out - принцип учета по которому первой списывается партия товара с наименьшим сроком годности.

** Логическая модель данных, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных

*** Как правило, время реакции на обращение зависит от стоимости обслуживания, и клиентам предлагаются различные тарифные планы. Перечислите в таблице все предлагаемые варианты.

При публикации материала ссылка на  http://consulting.1c.ru обязательна


Оставьте свои комментарии или пожелания

КУРСЫ ПРОГРАММИРОВАНИЯ ДЛЯ ШКОЛЬНИКОВ

+7(342) 28-700-48

54-ФЗ: ОН-Лайн кассы

1С: Клуб в соц сетях:

Баннер

1C_cso_red

Как удалить браузерный вирус

Баннер

Контактная информация

Россия, 614068, г. Пермь, ул. Сухобруса д. 27, оф. 303, 310

Телефон линии консультаций: +7 (342) 28-700-48, +7 (342) 237-15-83
Телефон / Факс: +7 (342) 237-15-83
E-mail по любым вопросам: info@inkast.ru


Ссылки на сайты партнеров: Торговля-и-Склад.РФ - автоматизация торговли на 1С (Пермь, Кунгур, Тверь)
Последние сайты: СНП Пальники, КВК-Сервис, Камакран

О нас

Наша компания занимается разработкой и внедрением автоматизированных систем управления. Миссия нашей компании: "Структуризация и решение управленческих задач". Мы помогаем предприятиям находить оптимальные решения с использованием современных технологий. Для получения информации о предоставляемых нашей компанией услугах перейдите в раздел Услуги.

Есть вопросы? Задавайте их на нашем форуме

Деловая сеть Пермь и Пермская область. Жёлтые страницы, телефонный справочник и каталог компаний, товаров и услуг.
Яндекс цитирования
Rambler's Top100