gifts2017

Внедрение минимальными ресурсами

Опубликовал Дмитрий Котлов (dim777777) в раздел Управление - Управление проектом

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

Для кого данная статья


Статья предназначена для специалистов, собирающихся внедрять системы автоматизации на базе 1с, в средних предприятиях численностью от 30 до 120 пользователей БД. 

Внедрение малыми ресурсами базируется, на мой взгляд, на 3 основных принципах: 1. Коммуникации 2. Поиск новых ресурсов 3. Определение необходимого минимума функционала

 

0. Стоит ли начинать.

Наверное, каждый хоть раз задавал себе вопрос: А стоит ли начинать?

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

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

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

в) История проекта: Есть проекты, которые никем еще не делались, а есть те, которые никем не доделывались.....  

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

1. Если решили взяться за дело

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

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

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

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

1. До начала поиска аутсорсинга у вас уже должны быть ТЗ, которые вы можете ему передать.

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

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

 

2. Разработка, проектирование системы и интервью

 

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

Соседи: Лучше опрашивать по несколько человек от каждого отдела, это даст более полную картину и убережет от ошибок.

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

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

 

3. Обучение и внедрение

 

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

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

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

1. Подготовка обучающего видео (т.к. оно наиболее просто воспринимается пользователями и может занять минимум времени на его создание)

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

 

4. Поддержка и развитие системы

 

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

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

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

 Дополненние

В дополнении я немного расскажу о планировании подобных внедрений. Для того что-бы посчитать сколько ресурсов и времени необходимо на тот или иной прект, можно воспользоваться несколькими способами: 1. Экспертный(в данном случае один или несколько экспертов высказывают свое мнение на эту тему). 2. Разбиение больших блоков на малые части, которые в свою очередь можно оценить. Я рекомендую комбинировать эти способы, т.е. на раннем этапе(когда еще не известен весь перечень работ) используется экспертная оценка. После проведение обследования используется второй способ. Если уже в процессе проекта высняется что в сроки вы не укладываетесь, то можно попробовать их сжать, а именно запустить парралельно несколько задач, которые до этого были запланированны последовательно, либо уменьшить объем задач(преварительно договорившись об этом). Учитывая спицифику проектов, а именно то что в процессе их реализации могут появиться задачи не учтенные при обследовании, а так же если вы используете в работах по проекту аутсорсинг то могут возникнуть задержки с выполнением работ по разным причинам(задержка оплат, не способдность делать в указанные сроки то или иное задание), рекомендуется полученную оценку срока и ресурсов умножать на 1,3 - 2.0 в зависимости от качества обследования и специфики проекта. Пример разбиения проекта на составные части и план графика раот находятся во вложенных файлах. 

Заключение

 

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

 

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
WBS
.doc 27,50Kb
12.08.13
6
.doc 27,50Kb 6 Скачать
План-график
.xls 30,50Kb
12.08.13
7
.xls 30,50Kb 7 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. evgen1977 (musatov1c.ru) 29.07.13 07:43
Для меня наверно самый главный вопрос в таких внедрениях: как его считать? Для меня самым сложным вопросом является план-график :) А так... Спасибо за статью. Немного с грустью прочитал о том, куда нужно расти :)
2. Дмитрий Котлов (dim777777) 29.07.13 09:14
Спасибо за комментарий. В беседующем дополню статью и план графиком с его обоснованием. Классический вариант различных план графиков и управление отклонениями по ним можно найти в стандартах PMI.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа