Как составить проект по внедрению деятельности

Время на прочтение
15 мин

Количество просмотров 57K

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

Для того что бы не объяснять каждому новому ПМу как делать план в Project’e и какие работы и какую структуру туда закладывать, я решил сделать некий драфт плана, который показывал бы типовую структуру работ по проекту внедрения и доработки простой информационной системы, стоимостью приблизительно 5 миллионов рублей и сроком около полугода. Условно, заказчик хочет стартовать проект в мае, а завершить в октябре, при этом старт проекта для нас — начинается в апреле, с подготовки пилота и КП.

Описание проекта

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

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

Риски проекта

Поскольку никакого Rocket Science в проекте нет, его риски составляют около 10%. Заложить их можно по разному — добавить 10% к стоимости ресурсов (но это не учитывает сроки), планировать работы с учетом рисков накидывая 10% длительности к каждой сколько-либо рискованной (именно такой вариант использовал я), или сделать этап Contingency перед завершающим этапом (в моем случае он бы составлял 3 недели или ~1/10 от длительности проекта.

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

Команда проекта

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

• Ведущий разработчик — он же архитектор. Участвует в проработке архитектуры решения, оценке задач по разработке, обеспечивает наставничество команде разработки и помощь в решении сложных задач.
• Разработчик — основной разработчик проекта,
• Младший разработчик — джуниор на подхвате кода, решает задачи под контролем разработчика, параллельно учится.
• Аккаунт — менеджер по работе с клиентами, отвечает за взаимодействие с клиентом, составление и подписание договоров, контроль удовлетворенности клиента и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
• Куратор — высший менеджер компании исполнителя, обеспечивающий контроль и поддержку проекта. Может быть так же — руководитель портфеля проектов и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
• Заказчик — все сотрудники заказчика, привлекаемые к проекту. В плане — не детализируемы, предполагается что заказчик сам решит, кого из своих специалистов привлекать к тем или иным активностям.

Конечно, нам нужно забить команду проекта на представлении «Лист ресурсов» — я просто указал роли, краткое наименование и внутренние ставки (они «средние по больнице» и не привязаны к конкретной компании), а так же указал свой базовый календарь (в общем, соответствующий производственному календарю на 2018 год). Если вы используете сервер проектов, в дальнейшем вы можете указать вместо роли — конкретных исполнителей, но на данном этапе — важны именно роли, для понимания необходимости сотрудников той или иной квалификации. Если вы готовите план проекта для представления заказчикам, есть смысл заменить внутренние ставки на внешние — и то и другое вы наверное уже знаете, а если нет — то это повод обратится к владельцам ресурсов, которые их откроют.

Минимум миниморум:

Конечно, роли могут быть другими — все зависит от компании (и методологии) в которой вы делаете проекты. Одним даром не нужен аналитик и внедренец, у них есть консультанты, другие делят аналитиков на бизнес и системных и добавляют техписателей, третьи используют стажерские программы с подключением сотрудников и т.д. У меня — один из множества вариантов команды, на листе ресурсов можно смело заменить сущности на свои и добавить новые.
Здесь, мы отмечаем заказчиков — зеленым цветом, а специалистов нашей компании, не подлежащих к расчету ФОТа — фиолетовым. Кроме того, что это наглядно, это так же удобно в дальнейшем, например если заказчик попросит сформировать график его привлечения к проекту — вы просто выгрузите план в Excel и отфильтруете по цвету.

Жизненный цикл проекта

В данном кейсе использован очень простой и распространённый жизненный цикл проекта — хорошо знакомый всем «Waterfall» где несколько фаз следуют друг за другом.

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

Так же для экономии места на экране я убрал отображение поля «Режим задачи» — на всех задачах он автоматический, ручного нигде нет.

Общий обзор этапов, их сроков и стоимости:

Итак, у нас есть 8 этапов (включая этап 0) и проект, который начинается 2 апреля, завершается 5 октября. Заказчику — можно вовсе не показывать этап 0, и конечно, не стоит его учитывать если вы не считаете ФОТ пресейлов и пилотов (но это для первый звоночек того, что вам есть над чем поработать, так как такой ФОТ считать нужно обязательно).

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

Этап 0 — подготовка проекта

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

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

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

При средних ставках внедренца и ПМа такой пилот будет стоить нам 59 400 рублей + еще 10800 рублей на его сопровождение, ведь у Заказчика появятся вопросы про его развертывание и использование. Ну как, вы все еще не хотите считать затраты на нулевом этапе?

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

Предположим, процесс описания скоупа и оценки у вас поставлен на поток, и после оценки куратор проекта одобряет ее (и накидывает % на торг и внепроектные риски) после чего КП отправляется на согласование заказчику. Здесь указанных 7 рабочих дней может быть явно мало, поэтому эта работа указана отдельно, и именно от нее зависит веха «КП Утверждено».

Разделять задачи по организации пилота и оценке скоупа проекта — надо, т.к. вы должны хорошо понимать их стоимость, и пытаться оптимизировать затраты на подготовку пилотов и оценку (например, создать типовые шаблоны для оценки и типовые виртуалки для внедрения).

Этап 1 — сбор требований

Итак, вы успешно подписали контракт (или получили одобрение от спонсора внутреннего проекта) и теперь самое время стартовать, начав со сбора требований к системе. Но перед этим, надо надо устроить kick-off meeting, или как это называется на русском, стартовую встречу.

В некоторых проектах есть смысл показать разработанный Project Charter, в некоторых проектах вместе с договором подписывается официальный устав, но независимо от этого кикофф нужен — для того, что бы ясно объяснить цели и сроки проекта команде (или командам) и познакомить всех друг с другом, договорится о взаимодействии. В общем, проведение Kick-off — это тоже тема отдельной статьи.

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

А вот кстати, и график встреч — для нашего простого проекта мы предусмотрели 6 встреч, на которых участвуют разные специалисты и которые стоят для нас по разному. Предполагается, что график мы заранее согласовали с заказчиками (или спонсорами), что бы бизнес-пользователи и вообще все заинтересованные лица, не ушли в отпуска или не были заняты на других активностях. Конечно, если вы работаете над внешним проектом, есть смысл включить план проекта в договор — в этом случае никто не сможет обвинить вас в срыве сроков, если заказчик по каким то причинам не сможет присутствовать на встречах.

Рассмотрим несколько встреч на примере:

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

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

Естественно, это идеальный вариант, который работает только при наличии 2 очень сильных и мотивированных проектных команд.

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

Этап 2 — Архитектура и дизайн

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

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

Есть ли смысл детализировать эти 5 дней в задачи и отражать их в плане проекта? На мой взгляд нет, логичнее сделать это в Jira/Redmine, а заказчику/спонсору показать такой план.
У меня предусмотрено 2 итерации согласования — это совершенно разумно, но требует от заказчика определенной ответственности — на берегу стоит объяснить, что все замечания к ТЗ Заказчик выставляет в одной итерации, а во второй — только проверяет их исправление, а новые замечания — не ставятся. Если заказчик настаивает на третей итерации замечаний — что ж, хозяин барин, вставляем и третью (и четвертую, и пятую…) не забыв прописать затраты и объяснить заказчику насколько вырастет стоимость проекта. Презентовать ТЗ первый раз разумно вдвоем с аналитиком, а вот вычитывать его необходимо всей команде — на сколько либо больших проектах это весьма емкий документ, который является условием для завершения фазы проекта (а следовательно подписания актов и оплаты), и случайные ошибки в нем не допустимы. Если у вас в компании есть свободные ресурсы, например аналитики, логично подключить их к чтению ТЗ в качестве свежего взгляда — ТЗ от этого хуже не станет, а проект не подорожает на сколько бы существенно.

Этап 3 — Разработка

Итак, техническое задание подписано, и казалось бы можно приступать к разработке.
Первое, о чем хочется сказать — это предупредить о недопустимости начала разработки, без утвержденного ТЗ. Это ведет просто к тому, что одну и ту же работу приходится делать 2 раза. Конечно, если вы работает по Agile, и у вас четких требований нет, а есть заказчик платит по схеме Time&Materials, тогда смело игнорируйте это требование. Если же скоуп проекта у вас утвержден, оплата FixPrice и вы не закладывали бюджет и сроки на переделку задач, то не позволяйте разработчикам сделать ни единого коммита, без подписанного ТЗ.

Второе — конечно подразумевается, что инфраструктура для разработки развернута, а процессы отлажены. Нерадивые спонсоры и кураторы проектов, стремятся включить в бюджет проектов такие расходы — переход на использование CI, развертывание Jira/Redmine, переход на новую версию ПО и библиотек, БД и т.д. и т.п. Задача ПМа здесь — защитить свой проект (и его бюджет) от такого, аргументируя что такие вещи должны быть вынесены в отдельные проекты с отдельными бюджетами.

Если вы работает по Waterfall — делать разработку стоит итерационно — т.е. разбить весь скоуп на части и показывать заказчику/спонсору по мере наработок. Пускай в софте еще будут баги, пускай нет данных, пусть формы не доделаны — лучше потратить бюджет и время на написание сценариев показа и дополнительные тесты, чем пропасть на месяц с глаз заказчика и появится с готовым продуктом. Фидбек заказчика на этапе завершения итерации разработки так же полезен, но это не значит что его надо бездумно пихать в скоуп — оцените его замечания. Если он предлагает что то несущественное — например, сменить цвет или размер поля на форме — покажите что вы лояльны и приветливо согласитесь. Если заказчик предлагает откровенно сложный функционал — откажитесь, аргументировав отсутствием в скоупе, а если заказчик настаивает — запускайте свою машину changemanagment’а (конечно, она у вас есть). Бывает, что заказчик предлагает казалось бы что то не существенное, например поменять формат телефонного номера, но это может сказаться на всей системе. В этом случае, посоветуйтесь с ведущим разработчиком/архитектором, возьмите его оценку под этой фичей, если она небольшая — можно пойти навстречу заказчику для повышения лояльности (но стоит помнить о риске ошибки оценки).

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

Этап 4 — Тестирование

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

Обратите внимание на задачу 110 (исправление дефектов) — она параллельна 109 (поиску дефектов) с задержкой в день. Т.е. предполагается, что тестировщик, проходя по тест-кейсам, описывает дефекты в системе задач, а разработчики правят их не отходя от кассы. Такой подход разумен и используется, но есть и другое решение — приступать к починке только когда тестирование будет завершено. Какой из этих подходов подойдет именно вам — знает ваш руководитель разработки.

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

ПМИ должен быть прочитан и утвержден заказчиком и именно по результатам прохождения ПМИ, заказчик будет принимать итоговое решение о переводе системы в промышленную эксплуатацию.
У меня в проекте — согласование ПМИ не включено, т.к. на моей практике, заказчики редко вчитываются в ПМИ и тест-кейсы, ибо слабо понимают о каком конкретно функционале идет речь и чем в одном случае чек-бокс отличается от радиобаттона в другом случае (это шутка, такое вообще в ПМИ писать не надо). Поэтому при разработке документа, особое внимание следует уделить списку кейсов, о прохождении которых пойдет речь, и конечно, проследить что бы они были нормально проработаны внутри.

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

Этап 5 — Внедрение

Ура! Мы добрались! Система на тестовых серверах работает как часы, команда QA отсыпается и уходит в отгулы, и пришел звездный час команды внедрения. Начинается он с развертывания окружения — и тут же у меня в плане заложен некий запас по времени, т.к. я подразумеваю что окружение развёртывали уже минимум 100 раз и в худшем случае на вашей корпоративной вике есть подробная инструкция по развертыванию, а в лучшем — внедренец сам ее писал. Главное, помните — после развертывания полезно протестировать все, что вы можете протестировать по заранее разработанному смоук-тесту, конечно же он остался у вас с фазы тестирования.
Теперь — о главном, ведь если дьявол и кроется где то, то это именно в интеграции и миграции данных. Сколько красивых диаграмм Ганта было погублено тем, что интеграция не была оттестирована тщательно и тем, что данные заказчика находились в ужасном состоянии, ненормализованные, выходящие за все грани разумного (и пределы полей), отличные от того, что написано в ТЗ.

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

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

На прохождение ПМИ — планируйте от 25% времени ПМа и выше, в зависимости от вашего опыта и годности аналитика, который участвует в проекте — в идеале испытания должны проходить как по маслу, ну и во всяком случае в этом должен быть уверен заказчик по крайней мере до начала испытаний.

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

Этап 6 — Поддержка

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

Теперь, ваша задача продержаться определенный период (от 5 дней до 4 месяцев) и убедится что система работает правильно. Выбор сроков зависит от назначения системы — иногда хватает и недели работы в новой системе, иногда нужно проработать в ней месяц или два, а то еще и квартал закрыть. Планируйте на это время людей, что бы они могли оперативно разобраться с возникшими у заказчика вопросами, но учтите, что вопросов может быть (должно быть!) немного — поэтому логично запланировать так же внутренние проектные активности — архивирование документации, приведение в порядок вики и трекера задач, подготовку ретро и т.д.

Не забывайте, что все проблемы, возникшие в ходе ОПЭ, надо фиксировать в специальном журнале (а в идеале — в трекере задач) и ежедневно отслеживать их статус совместно с заказчиком.

По окончании этапа можете так же запланировать одну встречу команды с заказчиком, где вы торжественно объявите о закрытии проекта и продолжении сотрудничества и подведете итоги. Если только ваш заказчик не в Новом Уренгое.

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

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

2000 г Как организовать проект внедрения. С.Н. Колесников, [it_info@iname.com] кандидат физико-математических наук Итак, вы приобрели продукт, на основании которого планируется создание интегрированной среды управления предприятием. В большинстве случаев, наверное вы догадываетесь, что внедрение — отнюдь не простой процесс, но, к сожалению, практика показывает, что до фактического «погружения» в проект обычно только специалист достаточно высокой квалификации может четко представить все будущие сложности. Как же быть ? К тому же на рынке широко обсуждаются различные варианты неудачных внедрений. К сожалению дать сколь-нибудь убедительную статистику по этому вопросу представляется крайне затруднительным, так как нет четкого и однозначно принятого всеми участники рынка определения термина «успешное внедрение». . Более того, например SAP AG предпочитает говорить не об успешных, а о «продуктивных» внедрениях, насколько эти термины совпадают по своей семантике? Трудно сказать совершенно определенно, но очевидно, что замена термина на более нейтральный и допускающий явно более широкое толкование — не случайна. Например, если первоначально предполагалось построить на базе одного продукта автоматизацию всех служб производственного предприятия. Но в процессе работы была реализована только функциональность логистики и бухгалтерии, а производственные модули были реализованы на базе другого продукта. Является ли такое внедрение успешным? Но продуктивным — безусловно. Также если продукт был приобретен и даже оплачен, а внедрение фактически не начато — можно ли вообще такую ситуацию считать внедрением, а тем более неудачным. А российские продукты? Легенда гласит, что они более легки во внедрении ? К сожалению, данный тезис не находит подтверждения на практике. При использовании одних и тех же критериев успешного внедрения и при одинаковой функциональности, показатели внедрения примерно одинаковы. Для продуктов, предназначенных для автоматизации крупных компании процент успеха можно оценить в 60 успешных внедрений на 100 продаж, для продуктов автоматизации более мелких компаний — не менее 80. Эти данные косвенно подтверждаются данными по западному ERP рынку Гартнер Групп, которая более осторожно изучает процент соответствия проектов внедрения плановым показателям и оценивает этот показатель для ERP систем также около 60 % (из них процент «досрочных» внедрений около 3%), а вот процент полностью провалившихся проектов в 10 %. Но нужно иметь в виду, что здесь рассматриваются только запущенные проекты, а в России есть значительный процент вообще не начавшихся проектов, а также проектов, замороженных на промежуточных стадиях на неопределенный срок по форс-мажорным обстоятельствам, как например смена собственника или августовский кризис.. Непонятно к какой категории относить такие проекты. Что касается сложностей внедрения иностранных программных пакетов, то, как известно, не бывает дыма без огня. С точки зрения психологического воздействия, внедрение западных продуктов как правило требует больших усилий, за счет другой организации финансового учета, непривычных интерфейсов, не всегда ясной терминологии, как правило из-за недостатков перевода. Опять же нужно различать внедрение тиражируемого продукта, то есть достаточно функционально жестко организованного, и внедрение с доработкой, когда производится существенная программная разработка функциональности и интерфейсов под требования покупателя. Во втором случае, характерном для российских продуктов, критерии успешности внедрения еще более размыты. Теоретически такого рода внедрения должны реализовывать всё желательные функциональные блоки, что на практике не имеет места. К тому же количество инсталляций продуктов многих российских продуктов обычно исчисляется десятками, а такую выборку трудно считать представительной, так как при таком количестве продаж велики зависимые факторы (с этой точки зрения и большинство западных продукты в России не имеют представительной выборки, но там можно воспользоваться западным опытом). Что же делать? Как обуздать процесс внедрения, который представляется необъезженным мустангом, кажется способным вырваться из любых пут? Но и на буйную стихию есть управа — желание и труд, помноженные на опыт и вековые правила. Так и процесс внедрения может стать в целом вполне предсказуем и управляем, если следовать принципам, изложенным далее в этой статье. Что такое проект внедрения. Рассмотрим некоторые стандартные параметры проекта внедрения корпоративной финансово-экономической системы, содержащей основные технологии планирования и управления материальными потоками, и, опционно, планирования и управления производством. По ходу проекта будут указаны стандартные проблемы и ошибки, которые обычно имеют место в Российской практике ведения таких проектов. При этом мы не будем касаться типично технических проблем, таких как, например, «перекачка» данных из существующей системы в новую, так как сейчас они обычно не становятся «камнем преткновения» проекта в целом. Ниже применяется термин СИСТЕМА для обозначения программно-прикладной системы, реализующей функции финансово-экономического управления, ПОСТАВЩИК / КОНСУЛЬТАНТ для обозначения консалтингового подразделения поставщика, принимающего участие во внедрении системы или внешнего консультанта, и Проект для обозначения процесса в целом. Определение стратегических целей проекта и тактического плана внедрения Задачей этого этапа является составление Базового плана внедрения, что включает организацию Проекта, структуру Проекта, цели и область применения проекта, состав проектной группы, методику внедрения, ориентировочный план подготовки проектной группы, согласование основных этапов, методы оценки качества работы. Наиболее серьезной проблемой данного этапа в Российской практике является его полное отсутствие или приблизительно-умозрительный характер. Необходимым условием успешности проекта является документирование всех решений принятых на данном и последующих этапах проекта. Предпроектное обследование промышленный аудит Задачей данного этапа является «ранняя диагностика» проблем, которые могут возникнуть при внедрении, среди прочих, можно упомянуть: выявление некачественно формируемых отсутствующих первичных документов, справочников, нормативов и стандартов, неподдерживаемая системой организация бизнес-процессов, процедур и правил. По результатам данного обследования должен формироваться подписываемый всеми участниками проекта документ, который описывает все выявленные проблемы и намечает пути их ликвидации. От качества проведения данного этапа работы и серьезности подготовленного документа часто существенно зависит успех проекта в целом. Со стороны Консультанта в этом этапе должны принимать участие специалисты высшей квалификации, крайне желательно имеющие опыт работы на предприятии данной отрасли или, хотя бы, в сходных отраслях. Одним из вариантов проведения данного этапа является одновременное проведение «промышленного аудита», то есть анализ организации бизнес-процессов и производственного управления на их соответствие отраслевым стандартам, принятым в мировой практике. В России данный этап часто превращается в платное ознакомление наименее квалифицированного персонала ПоставщикаКонсультанта с деятельностью предприятия, то есть по сути дела в их обучение, в результате которого формируется в лучшем случае бесполезный документ, якобы описывающий в какой-нибудь системе моделирования бизнес-процессы Заказчика. Обучение специалистов группы внедрения. Несмотря на кажущуюся простоту и очевидность, данный этап является источником огромного количества проблем, прчем именно в Российской практике. Прежде всего, из-за того, что абсолютное большинство российских предприятий морально совершенно не готовы заплатить существенную сумму за обучение своих сотрудников (типично — несколько десятков тысяч долларов), этот этап всем силами стараются сократить или вообще элиминировать не только Поставщики, но и сами Заказчики. Но дело в том, что последующие этапы ПРЕДПОЛАГАЮТ обязательное наличие у Заказчика обученного квалифицированного персонала. Если его нет — то эффективность последующей работы существенно падает, что в лучшем случае приводит к затягиванию проекта. В худшем — приводит к многократному росту его стоимости и даже провалу. Вторая проблема — качество и содержание программ обучения. В российских условиях для успешного ведения проекта группа внедрения должна обучаться на уровне консультантов по внедрению. Это требование не реализовано в большинстве программ обучения и тем более не поддержано квалификацией преподавателей. Более того, все западные программы предполагают, что участники обучения знакомы с основами западного бухгалтерского и управленческого учета, стандартами функционального и производственного управления. Естественно в наших условиях это неверно. Таким образом обучение начинается как бы с третьего курса — сразу специальные дисциплины, без общей фундаментальной подготовки. Каждый может прикинуть, как он чувствовал бы себя в подобной ситуации. В большинстве случаев это приводит к крайне низкому коэффициенту полезного действия процесса обучения, если не принять специальные меры. К числу этих мер можно отнести, в частности, соответствующий подбор группы внедрения и предварительное обучение ее участников фундаментальным дисциплинам. Моделирование бизнеса. Данный этап является необязательным, но обычно крайне рекомендуется в фирменных руководствах по внедрению. Российские консультанты всеми силами стремятся провести этот этап в ходе проекта, причем именно своими силами, так как он позволяет хорошо подготовиться к внедрению силами малоопытных консультантов. Но такое «моделирование», обучая консультантов, практически ничего не дает предприятию. Для того чтобы можно было извлечь из этого этапа существенную пользу, моделирование должно проводиться силами хорошо обученных сотрудников Заказчика с привлечением высококвалифицированных консультантов, с обязательно привязкой модели к стандартам бизнеса и к будущей системе. При наличии в системе встроенных средств моделирования, связанных со средствами быстрой настройки, как это реализовано, например в БААНе, такое моделирование может существенно скрасить жизнь системным администраторам за счет ускоренной настройки прав доступа и меню АРМов. Детальное планирование: После своего обучения группы по внедрению способны разработать детальный проектный план, специально предназначенный для эффективного внедрения. Перечни конкретных задач включают такие вопросы, как обязанности участников проекта, сроки начала и окончания работ, а также другие, вытекающие из них, параллельно решаемые задачи. Работа проводится совместно группой внедрения и Консультантами Разрабатывается и согласовывается настройка справочников и классификаторов системы в соответствии с выявленными на предыдущих этапах требованиями. При необходимости принимаются решения об изменении существующих практик учета или функциональных моделей. При наличии корпоративных стандартов и квалифицированных консультантов данный этап обычно не представляет особых проблем, кроме некоторых специальных случаев, таких как например очень широкая номенклатура выпускаемой продукции, очень большой уровень вариаций материалов и компонент и некоторые другие. Но квалифицированные Консультанты должны быть готовы к разрешению таких проблем. Типичная проблема России — это отсутствие корпоративных стандартов. Производится настройка системы в соответствии с принятыми решениями и тестирование функций проектной группой. Важнейшим требование на данном этапе также является наличие корпоративных стандартов, так как именно они являются основой настроек системы. Производятся тестовые пуски в отдельных подразделениях. В систему вводятся реальные данные, но как правило в ограниченном обьеме. Последовательно тестируются бизнес-функции путем моделирования, скажем, реальных ситуаций отгрузки товара, массового приходования на склад или производственного планирования. Очень важно провести эти испытания в условиях «максимально приближенных к боевым», чтобы исключить неприятные неожиданности на этапе опытно-промышленной эксплуатации. Пилотные примеры подразделений: В пилотных подразделений примерах (тестовых или пробных пусках) программное обеспечение будет использоваться для имитации работы одного или нескольких тесно взаимосвязанных подразделений. Каждое подразделение обычно выполняет свой собственный пилотный пример. Нужно иметь в виду, что на данном этапе интересы Консультантов и Заказчиков вступают в важное противоречие: консультанту важно провести этот этап наиболее «гладко», чтобы получить деньги за следующий, обычно самый дорогостоящий этап, заказчику же выгодно выявить как можно больше проблем именно на этом этапе внедрения, когда еще не поздно принять решительные меры, вплоть до отказа от внедрения отдельных блоков системы или даже всей системы в целом. Особенно стремятся на этом этапе «не обнаружить» проблемы Консультанты, участвовавшие в выборе системы и представители Поставщика. Обучение конечных пользователей работе с системой. На данном этапе обучение проводится обычно на рабочих местах и на настроенной системе. Российская специфика дает о себе знать и на этом, теоретически самом простом этапе. Вполне возможны случаи не только пассивного («не понимаю», «не удобно», «нет времени»), но и активного сопротивления, включая сознательные попытки вывести систему из строя, ввод недостоверных и заведомо опасных данных. Поэтому крайне желательно проводить данный этап с уже полностью настроенной системой разделения доступа и соблюдением всех мер и правил информационной безопасности. Как правило обучение проводится силами проектной группы Заказчика. Опытно-промышленная эксплуатация Опытно — промышленная эксплуатация проводится с целью убедиться в полном соответствии полученной в результате настройки системы функциональности, требованиям предприятия. Как правило на этом этапе сохраняется двойной ввод данных в старую и новую системы, ввиду чего нагрузка на учетные службы, задействованные в проекте, существенно возрастает. Интегрированный пилотный пример: На этой стадии будет полностью смоделирована вся деятельность предприятия. В нее войдут все основные бизнес-процессы, такие как ввод заказа, отгрузка, расчеты с заказчиками, управление запасами, снабжение, расчеты с поставщиками, главная книга и аналитический учет и т.д., необходимые для выполнения основных задач предприятия. Должен быть реализован полный учетный (как правило квартальный) цикл соответствующей деятельности, включая цикл закрытия периода. На основании результатов работы принимается решение о переводе системы в промышленную эксплуатацию. План «переключения»: Определение процедуры работ и фиксация специального графика перехода конечных пользователей на работу в новой системе, в особо ответственных случаях допускается параллельное ведение учета еще в течение некоторого времени, но желательно не более одного учетноотчетного периода, реально ввиду особенностей учета в западных системах рекомендуется производить переключение с начала года или, по крайней мере не позже первого квартала, что как легко понять, существенно ограничивает маневр для временных рамок проекта В ходе опытно-промышленной эксплуатации: получаются стандартные отчеты, с помощью системы и привычным образом и устанавливается идентичность данных, в отдельных случаях возможно проведение специальных верификационных процедур система может постепенно вводится в промышленную эксплуатацию, по отдельным участкам учета или управления документируются инструкции по ведению рабочих мест и корректируются должностные инструкции участников учетного процесса. Данные инструкции должны однозначно давать возможность определения источника ввода неверных данных и по возможности исключать их появление, в частности они должны содержать описание всех вариаций ввода и порядка применения стандартных справочников Ввод системы в промышленную эксплуатацию. Реализация данного этапа обычно и означает успешное внедрение. Хотя и здесь бывают особенности. Так, известны случаи, когда ряд функциональных блоков так и не передавался в промышленную эксплуатацию. Обычно это происходило в тех проектах, где этап тестовых пусков и пилотных примеров подразделений был проведен некачественно, в результате чего критическое несоответствие возможностей системы и бизнес-процессов предприятия выявлялось только на этапе опытно-промышленной эксплуатации. Послепроектное обследование промышленный аудит. Этот в общем то логичный этап, позволяющий оценить результаты работы и квалифицированно «подвести черту» под проектом, как это ни удивительно, практически не известен у нас. Кажется единственная компания, стандартно включающая его в состав проекта — это СОКАП. А теперь несколько шутливых тестов, которые позволят вам оценить готовность предприятия и вас самих к осуществлению проекта. Тест первый. Знакомы ли вы с Российским бухучетом — 2 балла Знакомы ли вы с Международными стандартами бухучета (или с GAAP) — 3 балла Знаете ли вы что такое хозяйственная операция — 1 балл если вы набрали 3 или более баллов в этом тесте — у вас хорошие шансы. Второй тест — ситуационный. Предположим, что в середине марта, в разгар работы над годовым балансом, вам необходимо отвлечь главного бухгалтера на 1-2 дня для проведения работ по внедрению. Руководитель проекта дает поручение главному бухгалтеру, его реакция: Забывает о поручении, положив трубку телефона После повторного напоминания идет жаловаться вышестоящему начальству Выполняет немедленно Шансы завершить проект вовремя и вообще его успешно завершить гарантированно есть только в третьем случае. Во втором — шанс есть, но скорее всего проект затянется надолго. И наконец, третий тест. Если возникла необходимость установить правила отражения незавершенного производства в бухгалтерских регистрах вашего филиала в Урюпинске, вы: Открываете фолиант корпоративных стандартов и просто читаете соответствующий параграф После часовых поисков «тетя Маша» находит среди своих «памятных записок» соответствующий листочек Вы безуспешно пытаетесь дозвониться до главного бухгалтера филиала, а когда дозваниваетесь, выясняете, что «Марь Иванна» в отпуске и выйдет через неделю, если успеет убрать всю картошку. Легко понять, что в последнем случае ваше положение незавидно, да и второй вариант вряд ли будет способствовать быстрому продвижению к цели, так как памятные листочки имеют тенденцию теряться в самый неподходящий момент, к тому же главбух может с тетей Машей не согласиться и начать искать свой листочек, а времени у него на это куда меньше, так что он может и не найтись до очередного баланса, ну а там, сами знаете … не до того. Ключевые факторы успеха. Если вы прошли все тесты успешно, это значит, что вашей организации присутствуют все три ключевых фактора, необходимых для успеха проекта внедрения — поддержка проекта со стороны высшего руководства компании, наличие обученного персонала, и наконец, наличие корпоративных стандартов учета и отчетности. Поддержка проекта. Наиболее важным фактором, без которого фактически не следует начинать проект. является фактор поддержки внедрения со стороны высшего руководства, а лучше собственников компании, и ее управляемость в целом. Последнее замечание существенно, так как существует, и довольно широко распространена, практика управления на основании «общественного договора», типичными примерами которых являются: «сам берет, но и другим дает», «рука, руку моет», ну и тому подобные. В этом случае формируется тип «коллективного» управления, когда формальное положение руководителя может совершенно не соответствовать его фактическим возможностям. Внедрение системы в таких случаях вызывает резкий конфликт интересов и даже при видимой поддержке со стороны всех заинтересованных сторон реально может столь же сильно тормозиться ими же, просто по причине несоответствия побудительных причин. Неудивительно, что лучше всего проекты внедрения осуществляются в компаниях с иностранными инвестициями и в частных компаниях, при наличии одного — двух собственников, если они, конечно, проект поддержали. Впрочем это обычно подтверждается фактором выделения денег на проект. В отличие от двух других факторов фактор управляемости компании практически не может быть изменен уже в ходе проекта, и как показывает и отечественная и зарубежная практика, его неучет, является основной причиной провалов большинства проектов внедрения. К сожалению в России большинство компаний управляются коллегиально и в связи с этим влияние данного фактора очень велико. Качественно может быть введен термин «управляемость компании», под которой будем понимать возможность безусловной реализации принятых на уровне высшего менеджмента решений и наличие механизма разрешения управленческих противоречий, которые достаточно часто возникают в ходе проекта. Косвенным, но также важнейшим следствием поддержки внедрения со стороны руководства компании служит состав группы внедрения. Проект идет существенно более эффективно, если в нее включены сотрудники функциональных подразделений — бухгалтерии, планового, производственного и других экономических отделов, отела закупок и продаж, отдела маркетинга и финансового анализа. Существует правда и успешная практика реализации проектов и силами только сотрудников подразделений ИТ, но в среднем такие проекты идут тяжелее и требуют более длительного периода обучения и «вхождения» в проблематику. Квалифицированный персонал. Наличие квалифицированного персонала — более динамичный фактор. Его влияние практически одинаково, как в отечественных условиях, так и в мировой практике. К тому же образование — дело наживное и поэтому не столь важно иметь уже обученный персонал, как важно его вовремя, и в нужном объеме, научить. Вот тут то и возникает уже чисто Российская проблема — не любят у нас тратить деньги на обучение, к тому же, когда эти деньги не маленькие, и очень даже не маленькие. Исходя из прайс-листов поставщиков ERP систем, можно оценить стоимость обучения проектной группы, то есть основных действующих лиц проекта, в суммы от 12 тысяч долларов, до 50-60 тысяч долларов и выше. Зная о сложности получения таких сумм многие поставщики пытаются спрятать эти деньги или вовсе отказаться от предварительного обучения, ссылаясь на то, что обучение пройдет «на рабочих метах». Это действительно возможно и практикуется — но только для конечных пользователей, которым ничего не нужно знать, кроме нескольких последовательностей клавиш, приводящих к нужному результату. Проектная группа должна знать все концепции программного продукта и взаимосвязь между ними — только тогда она успешно сможет вести проект. Вот на этом и играют недобросовестные поставщики — если нет обученного персонала, значит больше будут привлекаться консультанты, а обучение все равно придется проводить, но оно реально обойдется дороже, так как стоимость курса обучения в учебном центре для одного сотрудника клиента примерно равна или больше стоимости рабочего дня консультанта, а курс — 3-5 дней, считайте сами, что получится в случае индивидуального обучения. Корпоративные стандарты. И наконец третий ключевой фактор успех — наличие корпоративных стандартов. Минимально необходимый набор корпоративных стандартов изложен на врезке. Типичный перечень стандартов, совершенно необходимых ДЛЯ начала, а лучше ДО начала проекта внедрения — организационно-штатная структура предприятия бухгалтерские стандарты, включая общий план счетов ДЛЯ ВСЕХ участников проекта, типовой перечень хозяйственных операций, структуру аналитического учета, принципы консолидации данных, корпоративные принципы бюджетного управления и финансового анализа кодификатор и классификатор продукции и других товарно-материальных ценностей кодификатор и классификатор клиентов и партнеров, созданный с учетом целей анализа товарных и финансовых потоков стандарты процедур основных функциональных операций, по крайней мере особо критичных для бизнеса- продажа, закупка, складирование и внутреннее перемещение, и других, изложенных, например, в виде процедур стандарта ISO 9000, особенно если компания планирует его внедрение стандарты принятия решений и разрешения противоречий (специфично для России) Любая интегрированная система управления представляет собой некоторый замороженный срез такого набора стандартов. Естественно в данном случае мы не говорим о простейших бухгалтерских программах — «машинах проводок» или бухгалтерских калькуляторах. Если стандартов нет — то их придется создавать, и не важно, внедряете вы SAP R/3 или 1С. Правда, конечно обьем и уровень детализации будут разными, но принципиальный подход остается тем же — АСУ реализует некоторый вариант описанной и следовательно, хотя бы неформально стандартизованной системы отражения бухгалтерских и хозяйственных операций. Это не исключает возможности и даже необходимости проведения иногда нестандартных или разовых проводок или операций, что конечно система должна позволять делать. Однако утверждение, что «у нас все уникально и нет и не может быть стандартов» как правило оказывается тривиальным нежеланием проводить довольно трудоемкую и требующую высокой квалификации работу. Нужно признать, что работа по созданию корпоративных стандартов, если фирма действительно представляет собой корпорацию, может затянуться на весьма длительный срок, и уж точно будет длиться никак не меньше 4-6 месяцев ( в российской и мировой практике известны случаи, когда этот процесс затягивался … навсегда …, особенно если компания не полностью удовлетворяла первому требованию — управляемости) Но предположим, все вышеперечисленные требования выполнены, что же нужно делать? Управление проектом. Для эффективного управления проектом необходимо его преобразовать в последовательность действий имеющих четко определенные цели, ограниченных во времени и допускающих независимые процедуры верификации, то есть подтверждения правильности совершенных действий. Первая задача, которую нужно решить — сформировать управляющий комитет проекта, который должен иметь полномочия и возможность выполнять следующие задачи: принимать решения по утверждению корпоративных стандартов и изменений в них принимать оперативные решения в процессе производства работ оценивать деятельность групп на местах и при необходимости делать оргвыводы, вплоть до увольнения Процесс внедрения системы характеризуется множественным возникновением ситуаций «принятия решения», в частности, по вопросам стандартизации процедур и справочников, о чем уже говорилось, финансирования проекта, поощрения и наказания и т.п., что требует наличия группы «оперативного реагирования» с максимально возможными полномочиями. В принципе мониторинг процесса может осуществлять один человек, но высокая критичность принятых решений и их глубокая взаимосвязь с важнейшими бизнес-процессами компании требует принятия взвешенных решений с участием максимально возможного (с точки зрения обеспечения оперативности) числа представителей заинтересованных сторон. Однако представительство не должно превалировать над оперативностью решений, так как «ожидание консенсуса» способно уничтожить проект полностью, превратив его в саморазрушающийся «долгострой». Для оперативной реализации проекта нужно сформировать рабочую (проектную) группу в центральном офисе и на местах (филиалах), которая будет руководить и контролировать процесс в целом, готовить вопросы на утверждение управляющего комитета, осуществляет контакты с поставщиком и консультантами. Как уже говорилось в эту группе, кроме сотрудников отдела АСУ, должны войти, как правило на временной основе, сотрудники основных функциональных подразделений, затронутых проектом. Наличие этой группы не исключает необходимости создать в рамках отдела ИТ (АСУ) группу поддержки , задачей которой будет поддерживать функционирование системы как программного продукта как на этапе внедрения, так и после ее окончания. Минимальное количество сотрудников отдела АСУ для поддержания работоспособности системы «класса предприятия», то есть системы полностью интегрирующей все управленческие функции среднего или крупного предприятия (при односменной работе) — 4-6 человек, из них должен быть как минимум 1 — специалист — системотехник (то есть специалист по взаимодействию прикладных задач и операционно-управляющих систем), 1 — специалист по поддержке Базы Данных и программированию. Остальные — специалисты по прикладным подсистемам, сюда не входят специалисты по поддержанию работоспособности локальной вычислительной сети и технических средств связи, хотя в ряде случаев возможно частичное совмещение функций, но как правило не на этапе внедрения. Также не учтен персонал, необходимый для ввода данных при «неполном охвате» или «неполной интеграции» системы, что часто встречается при отечественной любви к «экономии». Естественно, в каждом подразделении, должны быть выделены и подготовлены «квалифицированные пользователи» обеспечивающие поддержку эксплуатации функциональных блоков продукта. При наличии сложноструктурированной или распределенной компании необходимо наличие дополнительного персонала обеспечивающего разработку и поддержание в актуальном состоянии учетных управленческих стандартов предприятия, возможно в составе экономических подразделений (бухгалтерии, планового отдела) или в виде самостоятельного подразделения. Далее придется создать или проанализировать на полноту корпоративные стандарты учета. Реально эту задачу может выполнить только хорошо обученный персонал или консультанты. Основным требованием здесь является наличие всех необходимых для функционирования системы справочников и классификаторов и соответствие принципов их организации требованиям системы. Основные справочники, о которых идет речь, это прежде всего: единый классификатор продукции, товаров и материалов, план счетов и аналитических признаков бухгалтерского учета, справочники дебиторов и кредиторов. Также ключевое значение имеет справочник основных хозяйственных операций или, что тоже, стандарты учета движения материальных и денежных ценностей. Уровень детализации корпоративных стандартов зависит от уровня интеграции бизнес- и финансовых процессов головной организации и подразделений. Наиболее простой вариант — чистый холдинг, то есть ситуация независимо хозяйствующих субъектов, итоги работы которых , как правило, консолидируются и оцениваются раз в год на уровне некоторого итогового (специального) плана балансовых счетов. Данный вариант пока редко используется в отечественной практике, так как отсутствует распространенная (принятая) методика консолидации учета, которая обеспечивала бы исключение внутрихолдинговых оборотов. Хотя в принципе российская практика учета уже позволяет использовать первый вариант — консолидацию практически стандартным (принятым на Западе) образом. Наиболее сложный вариант — «распределенное» предприятие, состоящее из нескольких территориально существенно удаленных филиалов, ведущих сложную хозяйственную деятельность, например производственных. Последний вариант особенно усложняется типично российской проблемой отсутствия хороших скоростных каналов связи. Региональная политика. Очень серьезной проблемой, часто встающей перед российскими предприятиями является проблема стандартизации учета и отчетности по всем своим местным региональным филиалам. Важно выяснить тот предел, до которого предприятие намерено и имеет возможность стандартизировать свою деловую практику по всем точкам локализации, филиалам, отделениям. Если в каких-то отделениях или филиалах нет возможности использовать корпоративные стандарты, то необходимо установить местные стандарты, иначе сама возможность реализации проекта в таких подразделениях окажется под вопросом. Но при этом следует иметь в виду, что при существенном отличии местных стандартов от корпоративных, внедрение в таком отделении может вырасти в самостоятельный проект. В ходе проекта следует определить местные различия стандартов и подходов к учету и отчетности и обсудить отличия в практике бизнеса и организации бизнес-процессов с тем, чтобы выделить специфику отделений и филиалов. Эта ситуация существенно может осложниться при происходящем сейчас быстром развитии системы местного налогообложения. Следующие отличия в бизнес-практике обычно не являются препятствием на пути проекта, так как поддерживаются многими программными продуктами и могут быть реализованы без существенных дополнительных усилий: Местная (филиальная) политика складирования по каждому продукту Распределенное размещение заказов на реализацию и прогнозирование деятельности производственных объектов. Совместное изготовление на нескольких производственных объектах (последовательный или параллельный производственный цикл). Управление контрактами заказами на глобальной основе. Централизованное распределенное планирование. Централизованное распределенное снабжение. Использование единой технологической иили проектно-конструкторской документации. Различные виды и регулярность отчетности, автоматизированная отчетность. Сохранение раздельной истории операций. Возможность получения аналитики по непредусмотренным заранее историческим разрезам данных Централизованные или местные модификации процедур и отчетов В то же время крайне существенные проблемы может вызвать отсутствие унификации в следующих стандартных справочниках и классификаторах: Кодирование классификация товаров, материалов и компонент. Классификация поставщиков Классификация заказчиков Учетная нумерация классификация первичных документов Методы и особенности нумерации частей и компонент готовой продукции (структуры изделия) Особо ответственные справочники, задача стандартизации и унификации которых представляет особую важность для компании: кодирование и классификация материалов и компонент представляет собой ключевой процесс, неудачная реализация которого может поставить под вопрос в лучшем случае сроки реализации проекта, а в худшем случае — весь проект в целом балансовые счета включая систему аналитического учета, причем они в случае внедрения систем западного производства — практически обязательно подлежат переработке финансовая аналитика данный справочник всегда требует переработки при внедрении автоматизированных учетных систем, особенно западного производства, в связи с другими принципами агрегирования и получения информации по «разрезам аналитики» клиенты (поставщики и заказчики) проблема ведения этого справочника достаточно серьезна, как и проблема его синхронизации между филиалами, данная проблема существует во всех системах, в том числе и российского производства склады и политика складирования при внедрении происходит изменение понятия Склад, так как к физическим складам добавляются «виртуальные» — технологические склады, такие как таможенный, «производственный» и пр., система складов должна быть разработана в связке с системой (технологией) товародвижения и учета товарных потоков Если вам удалось дойти до этого пункта , то осталось только … начать собственно процесс внедрения. Что осталось «за горизонтом» … Крайне редко (точнее — практически никогда) удается обойтись в данной работе без услуг внешних консультантов. К сожалению отечественный рынок управленческого консалтинга до сих пор только формируется. и не всегда можно найти специалистов для решения конкретных частных вопросов, которые возникают в течение проекта . При использовании же услуг западных консультантов следует иметь в виду, что стандартный (западный) проект внедрения системы исходит из некоторых перечисленных ниже предположений «по умолчанию», вообще говоря, неверных в Российской практике. Руководство предприятия имеет четкие стратегические и тактические цели, в том числе в области автоматизации, в частности, любой процесс начинается с постановки целей и оценивается по достигнутым результатам, времени их достижения и затратам. ( При этом существует или создается в ходе проекта адекватное письменное описание поставленных целей). Чего греха таить, сколько проектов остались «в потенции», только потому, что руководство потеряло интерес к ним сразу после первых выплат. Приоритеты находятся в области поддержки автоматизацией планирующих и управляющих технологий, а не отчетных ( во всех смыслах) процедур. Дело в том что многие, если не все, отчеты могут получаться и более простыми, в том числе и ручными, методами и как правило очень сложно обьяснить руководству, почем для их получения нужен дорогостоящий продукт. Для систем планирования ручная поддержка существенно более трудоемка, причем визуализируемо трудоемка. Руководство и специалисты заказчика умеют применять или, по крайней мере, имеют представление о стандартных технологиях управления бизнесом, таких как, SIC, MRP, Supply Chain, TQM и тому подобных., и не требуется специальное обучение в случаях использования их элементов в проекте (по крайней мере, в части технологий, уже используемых заказчиком). Именно по этой причине предварительное обучение, причем на уровне консультантов по внедрению, в России является обязательным требованием успешного проекта. Работает иерархическая структура управления — то есть распоряжения руководства безусловно обязательны для исполнителей. Участники проекта со стороны заказчика безусловно положительно относятся к повышению квалификации (приобретению знаний, умений) которая будет происходить в связи с выполнением проекта. Как это ни странно, это часто оказывается не верно, особенно на периферии, особенно если даже основная зарплата выплачивается с задержкой. Но и в Москве нередко можно встретить отчаянное сопротивление со стороны, например, сотрудников бухгалтерии. Это связано часто с тем, что такое обучение требует дополнительных затрат времени и сил, как правило сверх и так ненормированного рабочего дня, при отсутствии реальных материальных и карьерных стимулов. Если присутствует дополнительное материальное стимулирование процесса внедрения, то часто таких казусов удается избежать. И наконец, «личный» фактор. Вот это действительно бич российской действительности. Так как у нас отношения в коллективе существенно замешаны на личных отношениях, то изменение положения человека в худшую сторону всегда воспринимается как личная трагедия, а поскольку в группу внедрения привлекаются как правило специалисты имеющие статус «перспективных», то их отстранение от работ приводит часто к неадекватной реакции, вплоть до действий попадающих под определения саботаж и вредительство. Практически всегда имеют место попытки сформировать резко негативное отношение к проекту и его участникам. Тем не менее успешные проекты существуют и их количество продолжает увеличиваться. Это означает, что все перечисленные выше принципы являются вполне реализуемыми даже в отечественной практике. Причем их реализация не является чем-то сверхъестественным. Практически все вышеперечисленные требования являются базовыми требованиями к современной системе организации бизнеса и должны быть реализованы у любой уважающей себя фирмы. Что же касается собственно проекта, то главное — это серьезный и «технологический» подход к процессу внедрения, который позволит превратить его в действительно «процесс», а не в шаманские танцы консультантов вокруг компьютерного идола.

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

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

Объяснение плана реализации

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

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

Цели для плана реализации

Цель плана внедрения — описать, какие действия мы должны выполнить для реализации приложения.

Целью введения приложения [X] является:

• De SaaS приложение / программный пакет в инфраструктуру, чтобы он стал доступным для пользователей.
• Приложение [X] должно быть способно функционировать как направляющая и поддерживающая система для отношений с другими приложениями. В этом проекте мы также свяжем приложение [X] с приложением [Y].
• Конкретная задача приложения [X]: [вставить описание]

Конкретно это означает, что с помощью этого проекта мы закладываем основу для управления актуальными хорошими [полными] данными для отдела [завершено], что приводит к: [заполнить необязательно]

• [заполнить описание] данные доступны в режиме онлайн в отделе [заполнить описание] на каждом рабочем месте.
• Например, нет двойной передачи почты на один адрес.
• Интеграция функциональности как с приложением [Y], так и с приложением [Z].

План выполнения предпосылок / исходных точек

Для успешного входа в приложение [X] нам понадобится dienen randvoorwaarden и принципы. Они выступают в качестве основы для реализации.

Предпосылками являются:

• «Обязательства» руководства отдела [вставить описание].
• Организация имеет сходство с использованием автоматизированных инструментов в соответствии с большой регулярностью и интенсивностью, с которой выполняются проекты автоматизации.
• Финансовые ресурсы для покупки необходимого оборудования и программного обеспечения также должны присутствовать и быть доступными вовремя.
• Наличие и развертывание участников процесса внедрения (пользователей, команды проекта и т. Д.) Также необходимо.

Отправными точками являются:

• То, что ИТ-отдел вовремя вовлечен как участник процесса внедрения.
• Отдел внедрения как клиент отвечает за реализацию, т.е. руководит. Фактическая реализация, однако, заключается в различных рабочие группы.
• Чтобы внедряющая организация получила поддержку (или совет) в этой реализации со стороны ИТ-отдела при поддержке [вставить описание].
• утвержденный План проекта приложение [X].
• Тот для с отзывами также может обращаться к внутренним и внешним аудиторам. Они получают решающий ожидаемые / ключевые продукты для обзора.
• Отчетность передается руководству и [вставить описание].

Для обеспечения бесперебойной работы процесса внедрения важно, чтобы мы своевременно представили план внедрения ИТ-отделу. Это позволяет им планировать соответствующую работу. Где мы о Отдел информационных технологий вы также можете прочитать SaaS или Cloud provider.

Стратегия внедрения приложения / программного пакета SaaS

Для реализации приложения [X] мы используем определенную стратегию. Эта стратегия состоит из ряда следующих друг за другом шагов.

Стратегия состоит всего из следующих шагов:

• Настройка базы данных и модулей для приложения [X] (не применимо для SaaS).
• Создать и учредить управляющую организацию.
• Предоставление прав конечным пользователям.
• Добавление данных в базу данных с помощью Преобразование.
• При представлении приложения [X] мы также можем применить теневой период. Это связано с тем, что старая и новая система временно будут работать параллельно.
• Информация для отдела [вставить описание] в течение всего процесса внедрения.
• Прекращение старого приложения и отмена старых контрактов, если это применимо.

Результат проекта и демаркация плана реализации

Результатом внедрения приложения [X] должно быть то, что данные, относящиеся к приложению, будут доступны оперативно, онлайн и в актуальном состоянии сотрудниками отдела [введите описание].

Мы реализуем данные из приложения [X] в среде SaaS или в базе данных [вставить описание]. Мы также адаптируем дизайн этой базы данных в рамках этого проекта. Однако в какой-то момент мы определяем, какие данные мы записываем. Затем обсуждается право собственности на данные.

В этом проекте мы реализуем связь с приложением [Y] и [Z].

Проект внедрения будет иметь дело с описанием (составлением или доработкой) только критических бизнес-процессов. Они относятся только к использованию приложения [X]. Бизнес-процессы отдела [введите описание] могут измениться в результате внедрения приложения [X], так как может измениться ответственность за данные. Однако эти изменения должны обрабатываться экспертом AO. Кроме того, нам, возможно, придется создать временные процедуры. Они применяются до тех пор, пока не будут реализованы другие приложения или связи с ними. В конечном итоге за утверждение процессов отвечает руководитель отдела.

Команда по внедрению структуры проекта

Команда по внедрению проектной организации

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

• Организация управления отделом управления (клиент).
• Представление команды проекта (подрядчик).
• Различные рабочие группы.

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

Задачи для команды внедрения согласно плану внедрения

К основным задачам и связанным с ними обязанностям руководства отдела относятся:

• Проинструктируйте команды по реализации проекта.
• Предоставление финансовых, материальных и людских ресурсов.
• Утверждение основных продуктов и результатов.
• Утверждение плана.

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

Обязанности и связанные с ними обязанности Вступление команды проекта включать:

• Принять порядок реализации.
• Забота о хорошем персонале проекта.
• Визуализация и контроль затрат.
• Подготовка и мониторинг планирования.
• Готовим вводную заявку [X].
• Составление плана внедрения приложения [X].
• Реализация плана внедрения за счет управления рабочими группами.
• Надзор за выполнением работ.
• Координировать работу по реализации.
• Контроль за ходом реализации проекта.
• Отчетность о ходе реализации проекта руководству отдела.
• Составление отчета об оценке выполнения заявки [X].

(Основные) задачи и связанные с ними обязанности Рабочие группы являются:

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

Рабочие группы подкомитетов по реализации мероприятий:

• Команда Связи: Связь между приложением X и приложениями Y и Z.
• Тренинговая и информационная команда: создайте план обучения и определите информационный процесс.
• Команда процесса: опишите бизнес-процессы, связанные с приложением.
• Команда ввода: ввод данных / конверсия.

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

Обучение и информация о новом приложении (план внедрения подраздела)

Целью тренинга является передача знаний и обучение навыкам. Однако таким образом, чтобы на момент перехода задействованные лица могли работать с приложением [X].

Цель информации — проинформировать участников. И таким образом, чтобы они были осведомлены как о планировании, так и о ходе выполнения шагов.

Нам необходимо провести инвентаризацию того, какие пользователи будут обучаться работе с приложением [X]. Для подачи заявки [X] требуются знания о:

• De язык запросов (технология применения X).
• Пользовательский интерфейс (вход в систему).
• Управление записанными данными.
• Управление базой данных.

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

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

Информация о деятельности:

• Составление плана доступа к информации (для кого, что, как предоставляется информация).

Доставить: План обучения.
Доставить: Информационный план.

Заявление о найме персонала [X]

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

• Конечный пользователь, сотрудники отдела.
• DBA, администратор базы данных, отвечающий за управление базой данных. Это может быть сотрудник поставщика SaaS.
• Менеджер данных, сотрудник, который устанавливает и поддерживает отношения (в зависимости от ситуации, это может быть сотрудник отдела [вставить описание] или также другого отдела).
• Системный администратор, технический менеджмент. Это может быть сотрудник поставщика SaaS.
• Функциональный менеджер приложений.

Результат: Индивидуальный обзор кадрового приложения X.

Затраты на внедрение приложения [X]

В ожидании введения данных руководству отдела должно быть ясно, каковы будут затраты. Можно ожидать затрат на связь с приложением [Y}. После определения мы также запросим цитату у [company-o].

Мы советуем разбить котировку на фазу.

Мы предоставляем представление об окончательных затратах на основе основных продуктов «Приложение для проектирования системы» [Y] и плана обучения.

Поставка: обзор стоимости

Настройка приложения управляющей организации X

Цель этого этапа проекта:

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

Мероприятия включают:

• Проведите инвентаризацию и опишите все задачи и обязанности ролей, связанных с данными.
• Также заполнение (настройка) ролей, принадлежащих приложению [X] (администратор баз данных, функциональный менеджер приложений и т. Д.).

Поставка: Авторизованные сотрудники и гавторизованные администраторы.
Поставляется: (Custom) AO описания, включая временные процедуры.

Введение / Преобразование данных в новое приложение

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

Также важно, известны ли (части) данных уже в приложении X.

Какое бы решение мы ни выбрали для преобразования, всегда будут затраты на преобразование. Это связано с тем, что могут быть дополнительные возможности для ручного ввода и / или написания программ преобразования. Следующее относится к приложению X: [вставить описание].

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

Введение деятельности:

• Изучение качества текущих данных.
• Структурирование данных.
• Решите, следует ли выполнять ручное или автоматическое преобразование.
• Чистые (промежуточные) файлы данных.
• Выполнение и проверка конвертации (передача данных).
• Связывание пользовательского приложения [Y] с приложением [X] после преобразования.
• Проверить ссылку.

Результат фазы преобразования:

• Очищенные (промежуточные) файлы данных.
• Структурированные данные.
• Данные внесены в базу данных.
• Связывание приложения [Y] с приложением [X].

Результаты: план конверсии и Данные отчета о конверсии.
Поставляется: Отчет о ссылке приложения Y и проверка по нему (может отдельно).

Данные в производственной среде

Цель этого шага — доставить, а затем формально передать ответственность от приложения [X]. Это также включает новые бизнес-процессы, а также другие организационные изменения в базе данных. Мы также фактически устанавливаем связь между приложением [X] и приложением [Y].

деятельность:

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

Результаты этого этапа:

• Передано приложение в организацию пользователя.
• Соглашения о последующем уходе.

Поставляется: приложение в эксплуатации

Последующий уход после введения нового приложения (часть плана внедрения)

Целью последующего ухода является:

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

деятельность:

• оценка настроить.
• Закрыть проект.

Результаты этого этапа:

• Приложение интегрировано в организацию.
• Оценка проекта внедрения.
• Завершенный проект внедрения или отмена внедрения проектной организации.

Предоставляется: введение в окончательный отчет данные.

Расписание и узкие места в новой заявке

Для реализации приложения применяется следующая временная шкала.

Actie	1e неделя	2e неделя	3e неделя	4e неделя
1
2
3
4

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

Обсудить с нами LinkedIn.

Разработка бизнес-плана внедрения новой услуги на предприятии

РЕФЕРАТ

Тема выпускной квалификационной работы

«Разработка бизнес-плана внедрения новой услуги
на предприятии ООО «СК «СК»»

Автор работы: Завиваева А. Г.

Руководитель работы: к. э. н., старший
преподаватель Власенко М. Н.

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

Цель: разработка бизнес-плана внедрения новой
услуги (ремонт деревянных строений) на предприятии ООО «СК «СК» в Мурманской
области.

Задачи:

Проанализировать общую структуру бизнес-плана.

Проработать бизнес-план внедрения новой услуги
на примере предприятия ООО «СК «СК» в Мурманской области.

Дать экономическое обоснование внедрению
указанной услуги.

Научная и практическая значимость: результаты
работы могут быть использованы на ООО «СК «СК» как в теории, так и на практике.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

.
ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАЗРАБОТКИ БИЗНЕС-ПЛАНА

.1
Цель, задачи и особенности составления бизнес — плана

.2
Этапы разработки бизнес — плана

.3
Структура бизнес — плана

.
ПРАКТИЧЕСКАЯ ЧАСТЬ

.1
Резюме

.2
Характеристика предприятия

.3
Суть предлагаемого проекта

.4
Анализ положения дел в отросли

.5
Анализ рынка

.6
План маркетинга

.7
Производственный план

.8
Организационный план

.9
Анализ рисков

.10
Финансовый план

ЗАКЛЮЧЕНИЕ
И ВЫВОДЫ

СПИСОК
ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

ВВЕДЕНИЕ

Услуги по ремонту занимают не последнее место на
рынке. Около 30% людей в течение года производят ремонт, причём 10% выполняют
капитальный ремонт. Кроме того, до 2009 года продолжался стабильный рост доли
населения, прибегающего к услугам строительно-ремонтных фирм. Речь идет по
России в целом и в отдельных регионах.

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

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

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

Кризис существенно не изменил число компаний по
предоставлению ремонтных услуг на рынке.

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

Поэтому написание данного бизнес-плана и в
дальнейшем создание новой услуги является актуальным в настоящее время для
Мурманской области.

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

Цель: разработка бизнес-плана внедрения новой
услуги (ремонт деревянных строений) на предприятии ООО «СК «СК» в Мурманской
области.

Задачи:

.Проанализировать общую структуру бизнес-плана.

.Проработать бизнес-план внедрения новой услуги
на примере предприятия ООО «СК «СК» в Мурманской области.

.Дать экономическое обоснование внедрению
указанной услуги.

Объект исследования: ООО «СК «СК».

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАЗРАБОТКИ БИЗНЕС-ПЛАНА

.1 Цель, задачи и особенности составления бизнес
— плана

Бизнес — план это комплексное исследование
различных сторон деятельности фирмы. [4]

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

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

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

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

в) Готовый бизнес — план это средство
руководства, при помощи которого оно доводит идеи бизнеса до всех
заинтересованных лиц, в первую очередь до сотрудников фирмы. [4]

В свою очередь бизнес — план способствует
решению множества задач:

определяет конкретное направление деятельности
фирмы, ее целевые рынки и место данного предприятия на этих рынках;

формулирует долгосрочные и краткосрочные цели
фирмы;

определяет стратегию и тактику достижения целей
предприятия;

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

оценивает издержки по созданию и реализации
новых товаров и услуг;

производит оценку кадров фирмы и условия
мотивации их труда;

определяет маркетинговые мероприятия фирмы по
изучению рынка;

обеспечивает конкурентоспособность фирмы;

максимизирует прибыль в условиях рынка;

оценивает материальное и финансовое положение
фирмы;

оценивает соответствие ресурсов фирмы
поставленным целям. [13]

Бизнес — план это элемент управления, он
выполняет множество функций, главные из которых:

инициирование (бизнес — план активизирует,
стимулирует и мотивирует намеченные действия);

прогнозирование (бизнес — план предвидит и
обосновывает желаемое состояние предприятия посредством анализа и учета
факторов и их совокупности);

оптимизация (бизнес — план обеспечивает выбор
наилучшего варианта развития фирмы в конкретных условиях рынка);

координация и интеграция (бизнес — план
учитывает взаимосвязь всех структур фирмы и ориентирует их на желаемый
результат);

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

упорядочение (бизнес — план создает единый общий
порядок, это позволяет сделать работу более успешной);

контроль (бизнес — план предоставляет
возможность оперативно отслеживать достижение поставленных целей, выявлять
ошибки и их возможные корректировки);

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

Основные принципы бизнес — планирования.

а) Необходимость.

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

б) Непрерывность.

После окончания действия плана необходимо
разработать новый план (планирование должно иметь скользящий характер).

в) Эластичность и гибкость.

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

г) Единство и полнота.

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

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

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

ж) Оптимальность.

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

з) Связь уровней управления.

Необходимо детализировать план «сверху — вниз»,
укрупнять его «снизу — вверх». Также необходимо частичное делегирование
полномочий.

и) Участие.

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

к) Стабильность.

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

л) Адекватность.

Необходимо увеличивать число учитываемых
факторов и повышать уровень точности прогнозов. Кроме тех принципов, которые
разобраны выше в планировании, как правило, учитывают и общеэкономические
принципы. Например: научность, директивность, эффективность, приоритетность и
прочие.[16]

.2      Этапы разработки бизнес — плана

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

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

а) Обоснованная идея проекта и общие сведения о
данном проекте.

) Соответствие проектной идеи существующей на
данный момент системе экономических взаимоотношений в стране.

) Перечень спонсоров и причины их
заинтересованности в проекте.

) Основные характеристики проекта. Цели,
преследуемые проектом и его предварительная основная стратегия. Доля на внешнем
и внутреннем рынках, а также занимаемая рыночная ниша.

) Тип размещения проекта, представляющий собой
ресурсную и рыночную ориентацию.

) Экономическая политика поддержки проекта.

) Продукция и ее структура. Показатели мощности
предприятия.

) Контуры экономической, промышленной, социальной
и финансовой политики.

) Благоприятность национальных отраслевых и
подготовительных факторов для проекта.

) Общие сведения о проекте, включающие в себя
наименование, адрес, финансовые возможности и проч.

б).Анализ рынка, стратегия маркетинга, основы
проектной стратегии.

) Общеэкономический анализ рынка.

) Общеэкономические показатели спроса на
исследуемую продукцию или вид услуг, выпуск которых предусматривает данный
проект.

) Государственная политика, практика и
законодательство в сфере потребления, производства, импорта и экспорта
продукции, создание которой предусматривает данный проект.

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

) Имеющийся уровень импорта.

) Сведения о поведении, привычках, а также
реакции индивидуальных и групповых потребителях и данные о торговой практике.

) Исследования рынка.

) Прогнозирование изменений емкости
отечественного рынка.

) Перспективы выхода на рынки других стран.

) Импорт продукции или услуг конкурентов.

) Цели проекта, включая замещение импорта,
использование имеющихся ресурсов и проч.

) Общая стратегия проекта (лидерство в
издержках, ориентация на ограниченную группу потребителей, занятие ниши рынка)
— действия и средства для достижения поставленных целей.

) Стратегия маркетинга (вхождение на рынок,
развитие рынка, развитие выпускаемой продукции или предлагаемого вида услуг,
диверсификация).

) Оперативные мероприятия, включающие сбор,
обработку и систематическую оценку информации.

) Цели в области маркетинга.

) Доходы и издержки маркетинга.

в) Потребляемое сырье и комплектующие материалы,
их классификация, потребности и стратегия поставок.

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

д) Инженерная подготовка проекта и технология.

е) Организация и управление фирмой.

ж) Определение потребностей в трудовых ресурсах.

з) Планирование процесса реализации проекта.

)Этапы реализации процесса.

) Разработка и составление графика реализации.

и) Финансовый анализ, оценка инвестиций и
финансирование проекта.

)Анализ и оценка затрат, результатов и будущего
чистого дохода, выражение в финансовых категориях.

)Методические принципы.

) Объекты финансового анализа.

) Классификация издержек.

) Методы экономической оценки инвестиционных
проектов.

)Традиционные методы для оценки инвестиционных
проектов, включающие в себя метод определения срока окупаемости проекта, а
также метод определения простой нормы прибыли.

) Дисконтные методы оценки инвестиционных
проектов:

метод внутренней нормы окупаемости;

метод чистой дисконтированной стоимости;

метод дисконтированного периода окупаемости.

) Оценка инвестиционного проекта сразу по
нескольким методам с последующим выбором наиболее оптимального.

) Финансирование проекта и оценка потребностей.

) Акционерный капитал.

) Заемный капитал.

)Финансовые показатели деятельности
производства:

коэффициент задолженности;

показатель текущей задолженности;

показатель покрытия долгосрочного долга;

показатель отношения дебиторской задолженности к
кредиторской задолженности. 13) Экономические показатели, такие как
капиталпродукт, чистой дисконтированной стоимости, текущей прибыльности
инвестиций, эффективной занятости.[13] Формирование бизнес — плана, идеи
создания качественно новой или существенного преобразования уже существующего
предприятия идет в несколько этапов.

Этапы формирования бизнес — плана.

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

В этом случае фирма выступает в качестве системы
и понимается как:

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

социальная организация, сотрудники которой имеют
возможность для проявления и дальнейшего развития своих способностей и
удовлетворения последовательности;

конкурент прочим производителям товаров или
услуг;

социальная единица, которая учитывает интересы
окружающего общества;

часть общей рыночной экономики.[4]

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

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

Инициативы — сравнение имеющегося и желаемого
состояния фирмы, мотива действий.

Критерия принятия решений — оценки информации и
выбора альтернативных путей и приоритетов в бизнесе.

Ключевого инструмента управления — руководящие требования
действиям, определения направлений бизнеса. [16]

Координации — обеспечение не конфликтных
отношений лиц, участвующих в принятии решений, согласование работ
специализированных подразделений. [4] Контроля — сравнения оперативного
состояния показателей хозяйственной деятельности с их целевым уровнем.

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

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

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

.3      Структура бизнес — плана

В данной дипломной работе разработка бизнес —
плана будет осуществлена по следующей схеме:

) Резюме

) Общее описание компании.

) Анализ положения дел в отрасли.

) Анализ рынка.

) Описание предлагаемого проекта.

) План маркетинга.

) Производственный план.

) Организационный план.

) Анализ рисков.

) Финансовый план.

Как правило, бизнес — план начинается с
титульного листа, на котором указывается:

наименование проекта;

место подготовки плана;

авторы проекта, юридическое название и адрес
предприятия;

имена и адреса учредителей;

назначение бизнес плана и его пользователи. [13]

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

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

долю предприятия на занимаемом сегменте рынка;

ее сырьевую базу;

перечень потенциальных клиентов с их
возможностями;

региональную структуру производства;

основные фонды с их структурами;

инвестиционные условия.

Выбор сфер деятельности

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

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

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

И наконец, в заключительной части маркетингового
раздела происходит формирование плана сбыта продукции предприятия, при котором
дается подробное описание стратегии выхода на рынок, порядок оплаты
поставляемых товаров, прогнозируемый объем продаж на планируемый период [3].

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

а) основные — они непосредственно связаны с
превращением предметов труда в конечную продукцию;

б) вспомогательные — они, в свою очередь,
напрямую не участвуют в основных процессах, а лишь способствуют их исполнению.
[4]

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

Планирование трудовых ресурсов происходит при
помощи определения потребности в персонале, ИТР и служащих по категориям. Для
этого создается штатное расписание для рабочих и служащих отдельно.

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

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

Чтобы принять окончательное решение по бизнес —
проекту нужно четко определить инвестиции и производственные издержки. [7] При
этом необходимо учитывать инвестиции и издержки производства, при этом
прибыльность проекта в итоге будет зависеть от их размеров, структуры и графика
осуществления.

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

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

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

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

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

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

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

Учет финансовых последствий для заинтересованных
участников проекта отражает коммерческий уровень оценки.

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

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

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

При условии, что рентабельность инвестиций
превышает минимальный коэффициент дисконтирования, чистая текущая стоимость
имеет положительное значение. Когда значение ЧТС равняется нулю, рентабельность
проекта соответствует минимальной норме. То есть приемлемым принято считать
проект ЧТС которого не меньше нулевого значения. Если капитальные вложения,
связанные с предстоящей реализацией проекта, осуществляют в несколько этапов
(интервалов), то расчет показателя NPV производят по формуле (1).

 (1)

где CFt — приток денежных средств в период t;

It — сумма инвестиций (затраты) в t-ом периоде;

r — барьерная ставка (ставка дисконтирования);

n — суммарное число периодов (интервалов, шагов)

t = 1, 2, …, n (или время действия
инвестиции).[2]

Внутренняя норма доходности — IRR — это
процентная ставка, при которой чистая приведённая стоимость (чистый
дисконтированный доход — NPV) равна 0. NPV рассчитывается на основании потока
платежей, дисконтированного к сегодняшнему дню. Среди ключевых моментов
успешной реализации бизнес-плана находится расчет коэффициента дисконтирования.
Коэффициент дисконтирования дает возможность оценить величину инвестиций с
учетом риска и временного фактора. Расчёт коэффициента дисконтирования
производится по формуле (2).

 (2)

где Kd
— коэффициент дисконтирования,

i — дисконтная
(процентная) ставка,

n — порядковый номер
периода.

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

Анализ безубыточности подразумевает под собой
определение точки безубыточности, которой соответствует минимальный объем
выпускаемой продукции, при котором доход от продаж сравнивается с количеством
производственных издержек. [7]

К постоянным расходам принято относить кредиты,
начисляемые на них проценты, накладные расходы, амортизационные отчисления по
основному оборудованию; к переменным все прямые затраты, то есть то, что
зависит от объемов.

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

2. ПРАКТИЧЕСКАЯ ЧАСТЬ

.1 Резюме

Предприятие: ООО «СК«СК».

Цель проектирования: внедрение новой услуги.

Услуга, планируемая к оказанию: ремонтные
работы.

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

Спрос: имеет тенденцию роста.

Рынок оказания услуги: Мурманская область.

Основные заказчики: физические лица —
непосредственные потребители, юридические лица — генподрядные организации.

Конкуренция: предприятие может успешно
конкурировать на отечественном рынке, у предприятия имеются как преимущества,
так и недостатки по сравнению с конкурентами.

Продвижение товара: реклама в интернете, реклама
в периодических изданиях; консультации по вопросам технологии и качества
продукции, прочее. Период планирования: 12 месяцев

Прогнозируемый доход: 15 млн. руб.

.2 Характеристика предприятия

Компания ООО «СК»СК»,
зарегистрирована 19 ноября 2010 года, Инспекцией Федеральной Налоговой Службы по
г. МОНЧЕГОРСКУ МУРМАНСКОЙ области, в категории : «Строительство»,
«Строительство зданий и сооружений».

Основной вид деятельности предприятия —
строительство зданий и сооружений представлены в таблице 1.

Таблица 1 — Виды деятельности фирмы

Виды деятельности

Строительство зданий и сооружений

Подготовка строительного участка

Разборка и снос зданий; производство земляных работ

Разборка и снос зданий, расчистка строительных участков

Производство земляных работ

Производство общестроительных работ

Производство общестроительных работ по возведению зданий

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

Монтаж зданий и сооружений из сборных конструкций

Устройство покрытий зданий и сооружений

Производство прочих строительных работ

Монтаж строительных лесов и подмостей

Строительство фундаментов и бурение водяных скважин

Производство бетонных и железобетонных работ

Монтаж металлических строительных конструкций

Производство каменных работ

Производство деревянных срубов

Монтаж зданий и сооружений из сруба

Монтаж инженерного оборудования зданий и сооружений

Производство электромонтажных работ

Производство изоляционных работ

Производство санитарно-технических работ

Монтаж прочего инженерного оборудования

Производство отделочных работ

Производство штукатурных работ

Производство столярных и плотничных работы

Устройство покрытий полов и облицовка стен

Производство стекольных работ

Производство малярных работ

Производство прочих отделочных и завершающих работ.

Таблица 2 — Финансовые показатели предприятия
ООО «СК «СК» на 2014 г.

Месяц	Объем продаж (тыс. руб.)	Общая сумма издержек (тыс. руб.)	Величина прибыли (тыс. руб.)
Январь	737	635	102
Февраль	970	852	118
Март	845	731	114
Апрель	901	778	123
Май	840	780	120
Июнь	799	695	104
Июль	699	611	88
Август	701	603	98
Сентябрь	745	655	90
Октябрь	780	688	92
Ноябрь	802	712	90
Декабрь	745	848	103

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

Рисунок 1 — Организационная структура компании

.3 Суть предлагаемого проекта

В качестве новой услуги на предприятии ООО «СК
«СК» планируется ремонт домов из сруба. В Мурманской области такой вид построек
очень популярен. Виды таких построек:

Жилые дома;

Бани частные и общественные;

Дачные постройки;

Беседки;

Постройки для благоустройства;

Административные здания;

Кафе рестораны;

Гостиничные домики и прочие.

Предприятие ООО «СК «СК» производит срубы бревенчатых
домов ручной работы высокого качества. Однако, часто нужно не построить новый
объект, а отремонтировать старый. Такой услуги у данной компании нет. Срок
службы деревянного дома достаточно долгий (30-80 лет, в зависимости от
эксплуатации), он зависит от эксплуатации, но часто, из-за неправильной
эксплуатации могут появиться дефекты, которые нужно устранить.[20]

Ремонтные работы могут быть разделены на 3 типа,
они представлены в таблице 3.

Таблица 3 — Виды и характеристика ремонтных
работ

Вид ремонтных работ	Характеристика
Косметический ремонт	Характеризуется отделкой внешних и внутренних конструкций, заменой окон, дверей, заменой кровли, обшивкой фасада и прочее. Такой ремонт производится без вмешательства в несущие конструкции здания.[21]
Капитальный ремонт	Характеризуется вмешательством в несущие конструкции строения. После него необходим косметический работ.[21]
Вид ремонтных работ	Характеристика
Реставрационные работы	Характеризуются восстановлением несущих конструкций от отделки здания. Целью этого вида ремонта является восстановления первоначального вида строения.[21]

Процентное соотношение заказов ремонтных работ в
зависимости от вида работы представлено в диаграмме на рисунке № 2.

Рисунок 2 — Процентное соотношение видов
заказываемых работ

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

Таблица 4 — Перечень основных работ по ремонту

Выполняемая работа	Характеристика работы
Ремонт фундаментов	-Ремонт фундамента под деревянным домом; -Ремонт ленточных фундаментов; -Ремонт покосившихся фундаментов; -Замена фундамента; -Вентиляция фундамента; -Гидроизоляция фундамента.
Ремонт стен	-Ремонт покосившихся стен; -Замена сгнивших частей; -Утепление стен; -Переустановка дверей и окон.
Ремонт полов	-Ремонт деревянного пола; -Замена сгнившего пола; -Усиление конструкции пола; -Выравнивание пола; -Утепление; -Удаление перекоса; -Укрепление лестницы.
Ремонт крыши	-Ремонт конструкции крыши; -Замена сгнившей крыши; -Удаление провисания; -Выравнивание перекоса; -Замена старой крыши; -Чердачная вентиляция; -Ремонт кровли; -Удаление протечек; -Ремонт карниза.
Прочий ремонт	-Достройка дома; -Пристройка к дому; -Ремонт веранд, мансард; -Ремонт лоджий, балконов; -Обработка антисептиком.

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

.4 Анализ положения дел в отрасли

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

Сейчас очень популярны деревянные дома. Это
можно увидеть на рисунке 3. В нём представлена информация о процентном
соотношении домов из различных материалов в Мурманской области.

Рисунок 3 — Соотношение строений в Мурманской
области в зависимости от материалов строительства

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

Так же важным фактором является толщина бревна и
сучковатость. В этом плане у сосны есть преимущество, так как в ее нижней части
практически нет сучков. Эти же критерии и на материал для ремонта.[22]

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

Рисунок 4 — Соотношение деревянных домов разной
конструкции

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

Рисунок — 5. Диаграмма процентного соотношения
ремонтных работ

.5 Анализ рынка

Для России дома из дерева это традиция. На рынке
множество предложений — от каркасных домов и оцилиндрованного бревна до
клееного бруса. Цена на дом из рубленого бруса ручной работы различны, от 1500
до 15 000 рублей за 1 м² сруба. Качество, естественно, напрямую
зависит от цены. Соответственно и ремонтные работы будут завесить от этого.
[22]

Дешевые дома, как правило, обладают и низким
качеством: диаметр около 20 см и тоньше, антисептики не применяются вовсе.
Такие дома с эстетической точки зрения не очень привлекательны и требуют
обшивке со всех сторон. Часто они могут потребовать и дополнительного
утепления. Такое строение не отличается долговечностью, но строятся они очень
быстро. Такие дома могут начать наждаться в ремонте уже в первый сезон их
эксплуатации. По-другому обстоят дела с фирмами, производящими дома, которые на
первый взгляд выглядят как дома высокого качества. Цена 1 м²
составляет около 7 500 рублей. Такие дома выглядят очень красиво, но через
некоторое время дом дает сильную усадку, бревна растрескиваются и теряют
первоначальный вид и, естественно, нуждаются в ремонте. [20]

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

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

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

Таблица 5 — Анализ конкурентов

Признаки сравнения	ООО «Дома в Мурманске»	ООО «Домостроительная компания»	Беспамятных А.М., ИП
Цена	высокая	высокая	низкая
Качество	высокое	высокое	хорошее
Опыт, лет	7	5	3
Наличие рекламы	есть реклама	есть реклама	есть реклама
Наличие сайта	есть сайт	есть сайт	нет сайта
Профессионализм кадров	профессиональные кадры	профессиональные кадры	менее профессиональные кадры
Текучесть кадров	низкая	средняя	высокая

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

Отсутствие маркетинга и PR;

Качество организации оставляет желать лучшего;

Низкий уровень подготовки специалистов;

Низкий уровень компьютеризации.

.6 План маркетинга

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

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

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

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

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

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

а) Увеличиваются вложения в рекламу, это
увеличит срок окупаемости.

б) Конкуренты пользуются плодами труда фирмы,
которая вкладывает средства в увеличение спроса.

в) Удержать лидерство значительно проще и
дешевле, чем стать лидером.

г) Лидер хотя бы на первом этапе получает
хороший доход со спроса. Это позволит быстрее окупит вложенные средства.

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

В таблице 6 представлены прогнозируемые
показатели ООО «СК «СК».

Таблица 6 — Прогнозируемые показатели

Показатель	Количество
Плановая годовая производственная мощность, тыс. м3	5
Планируемый годовой оборот, млн. руб	15
Максимальная численность новых рабочих, чел	10
Новый управленческий персонал, чел	2

Основными направлениями развития предприятия
станут:

а) Наращивание мощности;

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

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

Таблица 7 — Первичная матрица

	+	—
Внешняя среда	Возможности (O)	Угрозы(T)
	1) возможность быстрого выхода на рынок; 2) возможность быстрого роста рынка; 3) возможность освоения новых технологий 4)широкая линейка услуг.	1) повышенная конкуренция при превалировании ценовых показателей; 2) отсутствуют нормативные документы по стандартизации новых технологий; 3)недостаток квалифицированных рабочих.
Внутренняя среда	Преимущества(S)	Недостатки(W)
	1) управление производством домов налажено,  2) оснащенность производственной площадки, 3) хорошая репутация фирмы; 4) социальная ответственность.	1) нет истории предприятия на рынке ремонта домов ручной работы; 2) нет рекомендаций клиентов именно по ремонту домов; 3) непостоянство денежного потока из-за большого периода оборота дебиторской задолженности; 4) достаточно высоки издержки производства.

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

Конкурентные активы. Использование преимуществ
компании для освоения рыночных возможностей (S-O);

Конкурентные пассивы. Преодоление недостатков
компании для нивелирования угроз (W-T);

Узкие места. Преодоление недостатков компании
для освоения возможностей (W-O);

Безопасность и защита. Использование преимуществ
компании для нивелирования угроз (S-T).

Таблица 8 — Стратегии

	S — ПРЕИМУЩЕСТВА	W — НЕДОСТАТКИ
О	Стратегия: Максимизация использования сильных сторон и благоприятных возможностей	Стратегия:  Минимизация влияния слабых сторон и максимизация использования благоприятных возможностей
Возможности	1.Стратегия быстрого роста (S1, S2, S3, О1, О2)  2.Стратегия распределения: капитальный ремонт, косметический (S1, S3, О1, О2,О3)	1.Стратегия географического расширения (W4, O1) 2.Стратегия внедрения менеджмента качества (W1, W2, W3, W4, O1, O2,O3)
Т	Стратегия:  Максимизация использования сильных сторон и минимизация возможных угроз	Стратегия:  Минимизация влияния слабых сторон и минимизация возможных угроз.
	S — ПРЕИМУЩЕСТВА	W — НЕДОСТАТКИ
Угрозы	1.Стратегия реорганизации с изменением организационной структуры (S1,S2,S3,S5,S8,T1,T7) 2.Стратегия распределения услуг с целью минимизации рисков: капитальный ремонт, косметический ремонт (S1,S2,T1,T6)	1.Стратегия лидерства по издержкам (W2,W4,T1) 2.Стратегия внедрения менеджмента качества (W1,W2,W4,T1,T2)

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

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

Покупателя можно разделить на 3 категории, это
представлено в таблице 9.

Таблица 9 — Категории покупателей

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

Маркетинг лучше направить на третью категорию.
Причины для этого:

а) Маркетинг более концентрированный, то есть
охватывает большее количество участников;

б) Не нужно тщательное маркетинговое
исследование, так как поведение профессионалов проще угадать;

в) Один профессиональный участник рынка
обеспечивать большой объемов заказов;

г) Исключительно профессиональные участники
рынка могут стать постоянными клиентами. Это обеспечит постоянный поток
заказов;

д) Рынок профессионалов достаточно узок и хорошо
информирован.

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

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

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

Профессионализм;

Соблюдение заявленного качества;

Приемлемая цена;

Наличие производственных мощностей;

Добросовестность.

Результат опроса клиентов профессионалов отражен
на рисунке 6.

Рисунок 6 — Требования к исполнителям

Основные требования конечного потребителя
зачастую не четкие и имеют свои особенности, которые в свою очередь не понятны
профессионалу:

Больше волнует цена, чем срок;

Не интересует процесс и масштабы предприятия.

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

Продвижение товара происходит в несколько
этапов:

Информирование возможных заказчиков о услуге или
формирование спроса;

Информирование возможных заказчиков о
предприятии;

Стимулирование заказчика к обращению на
предприятие;

Стимулирование возможного заказчика к ведению
переговоров о заказе;

Стимулирование заказчика к заключению договора;

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

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

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

Стимулировать заказчика лучше хорошей рекламой,
ее особенности:

Достаточная стоимость рекламы;

Внешняя привлекательность;

Содержание, которое подталкивает к обращению.

При личном обращении заказчика важную роль
играет внешнее впечатление от предприятия, умение вести разговор, внешний вид,
отношение к заказчику. При дальнейшем ведении переговоров очень важны
производственные возможности, организация производства, сроки и это не учитывая
качества и цены. На рекламу на телевидение, радио, др. СМИ не стоит тратит
время и силы. Реклама в периодической печати хороший вариант. Её можно
разделить на:

Реклама для создания спроса;

Реклама для информировании потенциального
заказчика;

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

В 21 века одной из самых действенных видов
рекламы — реклама в интернете и создание собственного сайта. Обязательные
мероприятия для этого:

а) Доменное имя второго уровня (около 2500
рублей в год);

б)