Ошибки команд или как стать лучше взято тут
Опубликовал Антон Степанов (Stepa86) в раздел Управление - Управление проектом
В этой статье я постарался собрать легко диагностируемые проблемы команд, которые мешают им стать лучше.
Рассматриваются только команды, которые
1) Являются командой. 1 человек - это не команда, 2 – тоже маловато
2) Не проектные команды. Многие ошибки применимы и к проектным командам, но упор сделан на команды фикси, которые по сути являются 2-3 линией поддержки
3) Вопрос индивидуальной компетенции опущен. Команда из новичков не может быть сверхэффективной, команда же из звезд может быть посредственной
Проблемы также имеют ограничения:
1) Всегда есть исключения. По моему опыту, проблема чаще является именно проблемой, а не особенностью
2) Решение любой проблемы имеет цену, цену на внедрение и цену на поддержание. Нужно понимать, что цена решения проблемы может быть выше получаемого профита, а значит, решение этой проблемы не имеет смысла
Если вам есть что дополнить или с чем-то вы не согласны – добро пожаловать в холивар в комментарии. Если вы нашли ошибку, опечатку и косяк в оформлении – напишите мне в личку.
1 Рисковые парни
Увольте их.
1.1 Нет бекапов
Что будет, если внезапно РБ (рабочая база) перестанет существовать?
Попробуйте устроить экзамен сотрудникам, которые отвечают за работоспособность РБ (Сис. админам, администраторам СУБД или отделу 1С).
Вводная:
1) Файл БД поврежден и восстановлению не подлежит
2) Диск, на котором крутилась БД форматнулся и доступа к нему нет
3) Молния ударила в серверную и все сервера, которые стояли по соседству с сервером БД, недоступны
Какую задачу, за какое время и бекап какой давности получится развернуть?
Как правильно настроить MS SQL сервер для работы с 1С
Автоматический бэкап средствами 1С, который обязательно сделается (без перезапуска сервера)
Резервное копирование 1С средствами MS SQL
Джоэль Спольски: перестаньте делать бэкапы
1.2 Нет хранилища конфигурации
Хранилище нужно для командной разработки и версионирования изменений. Если разработка ведется минимум двумя программистами, то как можно соединить их труд в одно без головной боли? Версионирование помогает понять, кто, когда и зачем (для хороших команд) менял в конфигурации, а также является некоторым бекапом конфигурации. Если умрет компьютер программиста – cf можно взять из хранилища, если умрет сервер хранилища, то из базы разработчика.
Групповая разработка прикладных решений
Хранилище конфигурации: создание и использование
Хранилище конфигурации: не очевидные особенности групповой разработки
Технология разветвленной разработки конфигураций (ИТС)
2 Слабая команда
Они постоянно в мыле, постоянно что-то переделывают и исправляют. Любую простую задачу сделают через месяц и неправильно
2.1 Нет списка задач
Если нет единого списка задач (беклог, багтрекер или аналоги), то команда просто не знает, что ей нужно делать, забывает делать то, что нужно, делает не самые важные задачи.
Что именно использовать в качестве списка задач – каждая команда решает сама. Чаще всего пишут что-то свое, кто-то использует ексель или гуглотаблички, кто-то использует что-то чужое, типа Redmine, Trac, JIRA итд.
Хорошей практикой является визуализация списка задач с помощью доски.
История одной доски от Макса Дорофеева (Часть 1, Часть 2, Часть 3)
2.2 Разработка в файловой, если РБ в клиент-сервере
Или другими словами – большое различие между архитектурой продукционной среды и архитектуры среды разработки. То, что работает в одной, может не заработать в другой. Ошибка передачи мутабельного значения в РБ – не очень приятная штука.
2.3 Конфигурация не поставлена на поддержку
Если захочется обновить конфигурацию – будут большие проблемы
Хитрости платформы: использование конфигурации поставщика
2.4 Разработка ведется без учета возможности обновления
Даже если конфигурация поставлена на поддержку, то это не гарантирует легкости в обновлении. Облегчить обновление могут такие правила, как: префиксирование своих объектов, использование обрамляющих комментариев, максимальное сохранение типового кода и т.д.
Как облегчить обновление нетиповой конфигурации?
Обновление конфигураций 1С:Предприятия 8. Прыжок через 20 версий
Технология обновления нетиповых конфигураций 1С:Предприятия 8
2.5 Регламенты СУБД не настроены
Отсутствие регламентов СУБД обычно означает, что о производительности никто не задумывается. Документ проводится 10 минут? А что вы хотели? Система сложная, много всего обсчитывает. Появление регламентов навряд ли ускорит проведение до нескольких секунд, но их отсутствие - явный признак пробела в знаниях.
Регламентные операции на уровне СУБД для MS SQL Server (ИТС)
Как правильно настроить MS SQL сервер для работы с 1С
2.6 Нет тестирования
Выполненные доработки никак не тестируются. В лучшем случае сам программист погоняет доработку под полными правами. Приводит это обычно к тому, что детские ошибки всплывают у пользователей, и при их исправлении вносятся новые. Как итог – регрессионная спираль смерти.
3 Обычная команда
Они выглядят профессионалами, они решают задачи, пользователи их ненавидят, руководители считают, что команда и так делает все возможное
3.1 Не выполняются стандарты и методики разработки
Стандарты и методики разработки – это такие шаблоны, которые уже доказали свою полезность.
Следование единым стандартам позволяет выдерживать единый стиль кода, уменьшая холивары в команде из-за расстановки скобочек.
Использование стандартов разгружает мозг и позволяет не выдумывать каждый раз какое-либо простое архитектурное решение, а использовать гарантированно неплохое. Оно позволяет не допустить массу ошибок в разработке и при этом программист даже не будет задумываться о них. Вот запрещено в модуле объекта использовать Предупреждение() и программист просто его не использует и каждый раз не думает, а почему нельзя и что может случиться, если все же напишу?
При использовании стандартов качество и скорость разработки сразу улучшаются на порядок.
Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8 (ИТС)
3.2 Изобретение велосипедов
Неиспользование типовых механизмов, придумывание того, что уже было придумано, и нежелание разобраться в существующем решении. Это все приводит к:
Проблемы, через которые уже прошли авторы готового решения и успешно их разрешили, придется решать заново, и не факт, что получится так же хорошо
Взять готовое сэкономит кучу времени
Невозможно использовать мощный рычаг сообщества, когда существуют много доработок, которые на свой велосипед точно не пойдут
Да вы и сами все знаете
Писать код с нуля или использовать существующую библиотеку?
3.3 Используются Выполнить(), Вычислить() и внешние обработки в РБ
Есть «Хорошие» внешние обработки и использование выполнения исходного кода, например, внешние печатные формы, внешние отчеты, сложнонастраиваемые методы получения данных в планировании… Но, если рабочие места или ключевая логика выполнена на внешних обработках – это привносит кучу проблем.
Внешний код не ловится проверками кода. Переименовали мы объект, протестировали всю конфигурацию, а после обновления отвалились обработки
Внешние обработки приходится отдельно версионировать и следить, чтобы все использовали актуальную. Нужно отдельно следить какая версия в разработке, какая на тесте, а какая работает в РБ
Если у пользователя возникает ошибка, то в журнал регистрации падает «Форма {25} тут пошло что-то не так». Выяснить источник можно только после общения с пользователем
Внешний код на порядок сложнее оптимизировать
На внешнюю обработку/отчет сложнее сделать ссылку в интерфейсе/форме
Внешний код несет угрозу безопасности
Ограничение на выполнение «внешнего» кода на сервере (ИТС)
Безопасность прикладного программного интерфейса сервера
3.4 РБ подключена к хранилищу разработки или не имеет хранилища в принципе
Если РБ подключена к хранилищу разработки, то как-нибудь в РБ уйдут недоработанные вещи и придется очень долго это вычищать или экстренно доделывать. Лучше не подключать РБ к хранилищу, а переносить изменения сравнением/объединением – тогда будет понятно, что выкатывается и что может отвалится. А еще лучше использовать отдельное хранилище и подключенную к этому хранилищу спец. базу для обновления. Это позволит разделить моменты выката изменений с их контролем и непосредственным обновлением РБ. Откатиться на предыдущую сборку становится проще, и история выката сохраняется.
Технология разветвленной разработки конфигураций (ИТС)
3.5 Нет выделенной техподдержки
Если есть программист, который зарабатывает 100 т.р. и к которому обращаются пользователи с возникшими проблемами, затруднениями или рутиной задачей (завести нового пользователя, поменять реквизит в закрытом документе и т.д.), то этот программист сможет сделать не очень много задач. Но если взять нового сотрудника на 30 т.р., который будет делать простейшие задачи, то производительность программиста может вырасти в 2-10 раз
Организация правильной технической поддержки (ITIL\ITSM\ИСО 20000)
3.6 Нет аналитика/консультанта/РП
Если техподдержка прикрывает «снизу», то еще нужен сотрудник, который будет прикрывать команду «сверху». Он будет ходить на совещания, рассказывать о нововведениях, активно переписываться с топ-менеджерами и делать другие вещи, для которых навыков программирования не обязательно. Обычно этот сотрудник является аналитиком/консультантом/РП и выполняет еще и свои функции.
3.7 Нет оцененного плана работ (беклог, спринтбеклог)
Развитие списка задач. Кроме того, что есть задачи, очень хорошо бы иметь приоритеты у этих задач (их назначает бизнес) и иметь оценки этих задач (их назначает команда). Имея приоритеты и оценки, уже можно планировать работы и отвечать на вопросы «А когда вы сделаете мою хотелку?». При оценке задачи приходится подумать, а что нужно сделать, чтобы ее выполнить, и очень часто всплывают неочевидные вещи, которые нужно уточнить, которые оказываются сильно трудоемкими или которые можно купить на Инфостарте, сэкономив пару недель разработки. Чем раньше это всплывет, тем лучше.
Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения
Как делать быстрые и точные оценки сроков разработки проектов
Оценка и планирование проекта
Оценка проектов
3.8 Нет обратной связи с пользователями
Первый принцип в манифесте Agile гласит «люди и взаимодействие важнее процессов и инструментов». Очень сложно создать что-то действительно ценное для пользователя/заказчика, не спрашивая его и не уточняя по ходу задачи. Если пользователь будет причастен к доработке, то со значительно большей вероятностью ему понравится результат.
Периодический сбор обратной связи и реакция на нее сильно улучшит отношение пользователей к команде разработки и позволит выявлять такие проблемы, на которые уйдет 15 минут времени, но сделает пользователя счастливее.
3.9 Не используется топовое железо при разработке
Чем лучше железо, тем больше времени тратит программист собственно на разработку и тем выше его эффективность. Что происходит, когда комп подвисает, выполняя какую-либо операцию? Секунд 5 программист ждет, пока это закончится, а потом он решает скоротать время и открывает браузер. Минут 15 работы вылетает сразу. А ведь программист не хотел лезть в интернет, он просто решил скоротать время из-за медленной работы ПК. Прирост в эффективности в 10% отобьет топовый комп для разработчика меньше чем за год.
Второй монитор в работе тоже весьма полезная вещь. Даже если на одном экране будет всегда браузер, то хотя бы переключаться программист будет быстрее, а еще может увидеть, что долгая операция завершилась, и можно уже возвращаться к работе. Да и работать с двумя мониторами удобнее. Слева может быть конфигуратор, а справа режим предприятия, слева конфигуратор приемник, а справа конфигуратор, откуда переносится код, и т.д.
Хотите быстро поднять эффективность и мотивацию команды – обновите им компы и сервера.
Сюда же отнесу более комфортные условия работы – отдельный тихий офис, кондиционер, приятная обстановка, большая доска для рисования и т.д.
3.10 Нет простейшей базы знаний
У каждой команды есть много информации, которую нужно где-то хранить, чтоб доступ туда имела вся команда (и не имели все остальные). Это логины и пароли, пути к базам и хранилищам, регламенты и документы и другая информация. Если программисту выдать новый чистый комп, то подборка такой информации позволит ему очень быстро включиться в работу. А ведь такая информация может еще и меняться.
3.11 Нет саморазвития
Если в команде никто не старается узнать что-то новое, не читает статей, книг, не следит за обновлениями стандартов и методик, не смотрит код в типовой – обстановка медленно превращается в болото, а мотивация падает. Особенно дело обостряется, когда программист 2 года просто сидел на попе ровно, ничего не изучал и не повышал уровень своих навыков и знаний, и тут он решил потребовать повышения зарплаты.
4 Хорошая команда
Удивляет скоростью внесения изменений. Большинство пользователей довольны системой.
4.1 Неритмичный выпуск обновлений
Это скорее следствие, чем причина. Когда процессы внутри команды стабильны и прозрачны, когда команда знает, что ей делать и новые задачи не могут ее выбить из колеи, тогда обновления становятся предсказуемыми и уже в начале цикла разработки команда может сообщить, какие именно изменения придут в ближайшее обновление.
4.2 Нет скриптов на повторяющиеся действия
Если какое-либо действие может выполнить компьютер сам, то пусть выполняет. Автотесты, автобекапы, авторазворачивание копии РБ – это все экономит время высокооплачиваемых специалистов, а также сильно снижает вероятность что-либо забыть или сделать не так. Бекапы ведь все всегда делают перед любым обновлением?
4.3 Нет двойного чтения кода
Это когда любую строчку кода, нового или измененного, прочитало как минимум два программиста. Один программист при написании, а второй одним из следующих способов:
Парное программирование – все о нем знают, но навряд ли кто пробовал. Заявлено, что качество кода повышается, а скорость даже выше, чем, когда 2 программиста работают по отдельности. Думаю, прирост скорости связан только с тем, что отвлекаться на что-либо, кроме программирования, становится неудобно.
Аудит кода – берется кусок кода на 500-2000 строк, собираются несколько программистов, в том числе автор куска кода, и обсуждают этот фрагмент, выявляя ошибки, плохой стиль, хорошие идеи и т.д. Такой формат очень и очень быстро поднимает уровень слабых программистов до уровня лучших из участвующих.
Проверка кода перед помещением в основную ветку – ответственный за основную ветку проверяет весь код, который поступает в основную ветку, и не принимает тот код, который ему не понравился по какой-либо причине.
Если программист знает, что его код будет читать еще кто-то, то он начинает чуть больше задумываться над стилем, выполнением стандартов, именованием, архитектурой. Обратная связь по коду учит его писать качественнее. А тот, кто читает, также может набираться опыта – как писать стоит, а как нет.
Также двойное чтение кода способствует улучшению коллективного владения кодом.
Стили парного программирования
5 советов по проведению хорошего обзора кода
20 причин проводить обзоры кода
4.4 Не используется автоматическое тестирование
Автоматическое тестирование позволяет быстрее ловить ошибки и смелее проводить рефакторинг и изменения в проекте. Код, который покрыт тестами, становится более красивым, более грамотно спроектированным. Но затраты на его внедрение просто огромны. Сюда же можно отнести нагрузочное тестирование, сценарное тестирование, автоматизированная проверка конфигурации
Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С
4.5 Не проводятся мероприятия по повышению юзабилити
Сюда относится все то, что обеспечивает более удобную работу пользователей. Для этого нужно уметь ставить себя на место пользователя, знать основы разработки пользовательского интерфейса и юзабилити, наблюдать за тем, как работают пользователи (по-научному - юзабилити тестирование), проектировать сценарии работы и многое другое.
Сделать формочку удобной иногда занимает в 10 раз больше времени, чем просто сделать формочку. И этой формочкой пользователь может пользоваться 8 часов в день, 5 дней в неделю.
Еще один важный момент – пользователи работают с интерфейсом совершенно не так, как это делаете вы. Если вы сделали суперудобную форму, в которой можете работать легко и непринужденно, то попробуйте понаблюдать за пользователями. Вы можете быть сильно удивлены их подходом: они не умеют пользоваться буфером обмена, работают только мышкой, не знают половины типовых команд, не используют 90% функционала и вообще не понимают, зачем они тут что-то делают. А еще может оказаться, что на рабочем месте нет мышки и монитор всего лишь 14 дюймов.
Дизайн пользовательского интерфейса. Искусство мыть слона
5 галочек: чеклист юзабилити
4.6 Не используются сервисы для мониторинга продуктовой среды
Жизнедеятельность РБ обычно не входит в обязанности команды разработки, но если там что-то перестало работать – кого обвинят в первую очередь? А через сколько в команде узнают, что не работает регламентное задание?
Так же контроль за серверами разработки позволяет избежать простоев и проблем при внезапно закончившемся месте на диске
4.7 Нет полноценной базы знаний
Хорошая и полноценная база знаний крайне полезна, но затраты на ее внедрение и поддержание так же крайне высоки. База знаний является полноценной, если команда может уйти в полном составе, взамен приходит новая команда и на все свои вопросы она может получить ответы в базе знаний.
Управление знаниями в компании-разработчике 1С
4.8 Нет ретроспективы
Ретроспектива – это обратная связь команды самой себе. Это обсуждение положительных и отрицательных моментов в текущей методологии разработки и поиск решений, усиливающих положительные и устраняющих отрицательные моменты. Каждый раз, когда команда решает, как избегать аналогичных проблем в будущем – она растет, она становится лучше. А коллективное вытягивание и обсуждение позволяет конструктивно разрешать конфликты до их обострения.
Многие считают, что самая важная практика в Scrum – это ретроспектива. Если выполнять ее регулярно и приводить в жизнь все те решения, что были придуманы – команда очень быстро растет.
4.9 Нет прагматизма в работе
Любое действие имеет свой профит и свою цену. Если цена превышает профит, то, может, не стоит делать это действие? Стоит ли тратить время на повышение качества одноразового кода? А внедрять автоматическое тестирование, если после обновления вываливается максимум одна ошибка?
Эффективная команда – прагматична. Она делает только то, на что затраты окупаются. Можно даже по каждой задаче из списка проставлять коэффициент возврата на инвестиции (ROI). Чем быстрее отобьется инвестиция, тем быстрее стоит выполнить задачу.
5 Команда мечты
Их не существует.
5.1 Высокоэффективна
5.2 Предсказуема
5.3 РБ работает без сбоев
5.4 Изменения быстро и безболезненно приживаются
Friday, December 30, 2016
Thursday, December 29, 2016
Как не обжечься на внедрении 1С.
Как не обжечься на внедрении 1С. взято тут
Опубликовал Дмитрий Макаров (pro-rok) в раздел Управление - Управление проектом
Как внедрять будем.
Статья для руководителей организаций планирующих внедрение на своем предприятии 1С. Описаны первые шаги заказчика к Автоматизированной Системе управления Предприятием. Статья написана руководителем проектов по внедрению 1С, основана на собственном опыте внедрений. При необдуманном подходе к внедрению, этот процесс превращается в головную боль для заказчика и станок по сжиганию денег. В данной статье описал, какие ошибки допускаются внедренцами и заказчиками, и как избежать больших финансовых вложений в собственную головную боль. В основном речь идет о внедрении конфигураций на уровне УПП и КА.
В данной статье хочу написать, какие ошибки допускаются внедренцами и заказчиками, и как избежать больших финансовых вложений в собственную головную боль. В основном речь идет о внедрении конфигураций на уровне УПП и КА. Так как, например внедрение 1С: Бухгалтерия по большому счету и не требует самого внедрения. Хотя в моей практике был случай, когда мы писали проект под внедрение БП, но в этом на самом деле была необходимость. И так …
Переходить будем ???
Во первых, решение о том, что в учете необходимо что то менять, должно приниматься клиентом для начала самостоятельно, а только потом необходимо обращаться за консультациями в компании занимающиеся внедрением 1С. Данное решение может принять, например ген. Директор совместно гл. бухгалтером, ну и, например коммерческим директором или техническим директором, если такие есть. Основная причина это: переход на новую учетную программу или регистрация организации.
С регистрацией нового предприятия все понятно, тут мы начинаем с чистого листа и необходимо вести, где то учет. Но если у кого то из руководителей возникает желание перейти на новую учетную систему, например с БП на КА, то стоит задуматься, а нужно ли? Если «старая» учетная система себя оправдывает, работает стабильно и не существует проблем, и она устраивает на 100%, то возможно и не стоит трогать то, что хорошо работает. Ну а если, например Ваша система устарела как 7.7 или есть определенные сложности, проблемы в ведении учета, то стоит задуматься о переходе. Кстати при принятии подобных решений было бы неплохо проконсультироваться со своим рядовыми сотрудниками: менеджеры, мастера, логисты и т.д. Подобные люди дают наиболее красочное представление о работе предприятия, чем их руководители.
Я сам на обследованиях предприятий много раз слышал от руководителей о том, что их все устраивает и вообще жизнь замечательна. Но пообщавшись с работниками склада, менеджерами по продажам понимаешь, что руководители живут в иллюзиях, а сама работа происходит на местах и именно, там существуют проблемы, которые в последствии могут вылиться неадекватной отчетностью для руководителя, на основании которых ОН примет неадекватное решение, или что хуже всего вообще ничего не предпримет. Потому что у нас как всегда все хорошо!
А нужно ли внедрение???
И так вы на своем предприятий приняли решение, что необходимо, что то менять, так как бизнес в современном мире очень динамичен, и, отстав сегодня на пол шага, завтра окажешься на обочине. В первую очередь, о чем стоит задуматься заказчику, а действительно ли на его предприятии необходимо внедрение. Или же можно обойтись просто установкой.
Например, приобретаем программу, зазываем экспресс обучение и перенос остатков. Далее небольшое сопровождение на первые пару месяцев по 20 часов или и того меньше. Ну и все, следом идет ежемесячная установка обновлений и консультации по мере необходимости. Такой сценарий развития событий подойдет, если вы планируете работать на БП, УТ, ЗУП.
Это внедрением назвать тяжело, хотя и можно. Но это не внедрение в нашем понимании. Будем это называть «Экспресс Внедрение». Как можно определить нужно ли предприятию полноценное большое, ДОРОГОЕ внедрение или экспресс внедрение? Конечно, все захотят экспресс внедрение, это быстро и дешево. Но не будем забывать, что наша задача не нажить себе головной боли и не заплатить потом (после «какого-то» внедрения) еще больше, но только за то что бы все более, менее заработало. Задача любого предприятия получение прибыли с наименьшими затратами, поэтому стоит оценить затраты до первого шага.
Один из критериев большого внедрения: объем документооборота, например, ваша организация ежедневно производит на свет по более 60 документов. Это плюс в сторону внедрения ну так скажем не большой.
Следующий не менее важный критерий - сложность учета. У меня был опыт когда я разрабатывал проект, на который потратил пару месяцев, проект был по внедрению БП. Казалось бы куда проще. Но там была своя изюминка это специфика работы (СТО + авто магазин). Были большие сложности в учете НДС и совместном использовании ОСНО + ЕНВД. Информация сливалась в БП из других программ, и наша задача была максимально упростить бухгалтерский учет на предприятии и плюсом сделать его мобильным. Что бы при любом изменении схемы документооборота на предприятии, можно было быстро (с помощью настроек, а не программирования) изменить схему загрузки данных в БП.
Третий не менее важный критерий, это количество сотрудников предприятия занятых в создании первичных документов. На многих небольших предприятиях оформлением первичных бухгалтерских документов занимается непосредственно бухгалтерия, это конечно хорошо, если они справляются с собственными задачами, но при некотором объеме документооборота бухгалтерия начинает максимально упрощать собственный документооборот, так как не успевает делать это оперативно. Например, вместо ежедневного списания ТМЦ, оформляется раз в месяц по каким-то запискам. В результате получаем не оперативный учет, а «посмертный», которым управлять собственно и невозможно, только наблюдать за ним. Поэтому намного упрощает жизнь, когда оформление первичных документов делегируется на других сотрудников, например кладовщиков и менеджеров по продажам. Соответственно, если в вашей цепочке документов учувствует как минимум 3-4 звена (например: кладовщик – приход/расход ТМЦ, менеджер по продажам – заказы покупателям, бухгалтерия – платежи, и т.д.), то для работы этих сотрудников необходима СИСТЕМА и РЕГЛАМЕНТ работы. Что в свою очередь вас подталкивает на внедрение.
Четвертый САМЫЙ ВАЖНЫЙ. На предприятии есть проблемы: например воровство, сложность в организации поставок/отгрузок, хаос в учете и остатках и т.д. Тогда внедряемся.
Цели!!!
Целеполагание является одним из самых важных этапов внедрения, я бы даже сказал: «наиважнейшем». Так как сами понимаете, что если двигаться в никуда, то никуда и не придешь. Основная задача заказчика, точно понимать: «Что он хочет получить от внедрения». Соответственно, как сформировать грамотную цель для проекта внедрения???
Ваша цель должна находиться ЗА рамками 1С. Когда приходишь к заказчику часто слышишь фразы наподобие: «Чтоб все работало», «Чтоб не тормозило», «Что бы было много аналитики», «формировать пачку документов в программе понажатии на одну кнопку» и т.д. Это не цели, это «хотелки». Повторюсь, настоящая цель внедрения находиться в бизнесе, за рамками 1С.
Разберем пример основной цели одного из внедрений - «Увеличение пропускной способности в отделе продаж», но стоит оговориться, что без увеличения штата отдела продаж. Задача в следующем в отдел продаж звонит большое количество клиентов, и отдел продаж не справляется. Очень подходящая цель решаемая средствами автоматизации. Для решения задачи необходим комплекс мер, это работа производства, в режиме on-line, оперативное информирование отдела продаж и т.д. К этому можно добавить личный кабинет в интернете для постоянных клиентов.
Как было раньше, клиент звонит в отдел продаж «Как там мой заказ № 123». После чего менеджер звонит в производство и спрашивает «Что с заказом № 123». Получает ответ, и перезванивает клиенту, сообщая о результатах разговора с цехом. На что тратилось большое количество времени.
Как стало сейчас. Клиент звонит и говорит номер заказа, менеджер набирает номер в своей программе и получает полную информацию по интересующему заказу, может не вешая трубки проинформировать клиента. При необходимости скорректировать дату производства и моментально получить ответ от программы о возможности подобной корректировке. Наличие подобной информации в режиме on-line позволяет организовать личный кабинет клиентов, и получать информацию не беспокоя менеджеров по продажам.
Хорошую цель можно измерить. Идеальная задача, это задача, которую можно измерить до внедрения и после. Если вернемся к нашему примеру, то соответственно можно измерить количество звонков и среднюю продолжительность одного звонка. По итогам внедрения можно увидеть, что количество звонков за рабочий день увеличивается, а длительность соответственно уменьшается. Если к этому количеству прибавить заходы в интернет кабинет по длительности звонка 0 минут, так как не тратиться время менеджера, то получаем результат в увеличении пропускной способности отдела продаж на хороший процент.
Хорошую цель можно, а скорее нужно пересчитать в рублях. Например, можно оценить, сколько потребуется вложений в организацию одного дополнительного рабочего места это: телефонный номер, компьютер, стол, ежемесячная зарплата нового сотрудника, отчисления с ФОТ, расширение офисных помещений и т.д. С противоположной стороны будет стоимость внедрения 1С. Так же примерно просчитать количество клиентов, которых сможет обслужить один менеджер до автоматизации и после. Проект автоматизации бизнеса необходимо рассматривать с точки зрения прибыльности, а не убыточности. И соответственно ставить цели, которые помогут сэкономить: на фонде оплаты труда, офисных помещениях, на более выгодных закупках и т.д., которые, помогут увеличить приток клиентов и уменьшить себестоимость товаров, повысить оборачиваемость капитала.
Основные вопросы на которые должны отвечать ваши цели: как это поможет увеличить прибыль предприятия, как это поможет снизить затраты предприятия, либо избежать дополнительных расходов в будущем, и как это поможет увеличить управляемость предприятия.
Примеры целей:
Пресечение экономически не прибыльных закупок (не слишком маленьких (из-за отсутствия скидок и не оптимальной транспортной логистики) и не слишком большой (для недопущения перегрузки склада на длительный период и переплаты за владение капиталом)).
Оптимизация раскроя материала в производстве. Уменьшения возвратных отходов.
Управление качеством продукта (контроль над производственным процессом, материально-трудовой контроль, контроль выходной продукции).
Сбор или пересбор заказов. Управление резервами. Система автоматическогопере резервирования при получении более срочных заказов.
На самом деле сформировать «красивую» цель для конкретного проекта автоматизации задача достаточно сложная, и не решается в один миг. Поэтому перед встречей с командой внедрения не обязательно знать свои цели досконально, достаточно просто иметь приблизительное представление о своих желаниях по автоматизации. А руководитель проекта автоматизации поможет сформировать окончательную цель и разработает план по её воплощении в жизнь. Но сама идея должна исходить от заказчика, так как лучше самого заказчика, никто не знает его бизнес, и процессы, происходящие внутри компании. Руководитель проекта внедрения лишь придает нужную форму идеям заказчика, используя свой опыт внедрения на других предприятиях.
Первая встреча.
Итак, вы решили внедряться. У вас есть предпосылки для внедрения, вы имеете идеи, которые хотите воплотить в жизнь в ходе проекта автоматизации. Пора обращаться к франчайзи 1С. Для начала Вам, конечно, необходимо купить саму программу 1С. И позвонив во франчайзи, первым делом попадаете на менеджера по продажам. Вариантов развития событий множество в зависимости от грамотности менеджера и его добросовестности. Поэтому рассмотрим несколько вариантов.
Самый худший вариант развития событий. Менеджер предложит Вам организовать встречу. Приехав на ваше предприятие, будет рассказывать какую хорошую программу он вам продает, показывать слайды, отзывы и листовки, уверять, что все будет работать замечательно внедрение не дорогое и достаточно быстрое. НЕ ВЕРТЕ ЕМУ. Главная задача менеджера по продажам ПРОДАТЬ. А внедрением будет заниматься другой человек и это будет головная боль другого человека и заказчика. После продажи, к Вам приедет программист, который будет заниматься внедрением на вашем предприятии. Возможно, у него возникнет мысль о том, что клиенту продали совсем не то, что ему нужно и продали лишь бы продать. Но он вам об этом НЕ СКАЖЕТ, так как нехорошо подставлять компанию, в которой работаешь. И программист будет работать с тем, что продали. +1 к головной боли.
Второй вариант развития событий. Менеджер приезжает к заказчику совместно с программистом. Программист проводи для вас демонстрацию работоспобности и функционала программы. Он будет вам показывать как организованны закупки, продажи, планирование, производство и т.д. Хочу заметить, что он приедет к вам с готовой базой для демонстрации. Уверяю, на ней будет работать ВСЕ. Эта база специально предназначена для демонстрации, данные в базе и решаемые в ней задачи идеально подобранны друг к другу. В реальной жизни такое редко встречается.
В моей практике был случай, когда клиент выбирал франчази и устроил тендер на внедрение. В тендере учувствовали две компании (наша и еще одна). Обе компании проводили презентации программы. В результате, презентация конкурентов понравилось больше, чем наша презентация. И они согласились купить, но внедряться стали у нас (цены наверно понравились). Когда мы дошли до внедрения планирования, я рассчитал стоимость внедрения данного блока. Заказчику это очень не понравилось, из-за большой суммы внедрения. Сумма и сроки ввели в заблуждение заказчика, так как на презентации наши конкуренты показали, как легко и быстро можно пройти от плана продаж, до посменной загрузке оборудования в производстве (конечно, показывали на своей демонстрационной базе). А на самом деле в работе заказчика встречался ряд нюансов, которые было необходимо учесть, при планировании. В результате путь от плана продаж до плана производства оказался достаточно тяжелым, долгим и не обеспечивал 100% точность конечного результата. Альтернативой было доработка типового функционала, которая требовала времени и финансовых вложений. В результате смотреть презентацию функционала программы, конечно, стоит, но относиться к этому необходимо скептически.
Идеальный вариант развития событий. Когда проводиться презентации для заказчика, для общего понимания работы системы. Следом исполнитель предложит заказчику провести обследование предприятия. Порезультатом обследования можно будет провести оценку стоимость внедрения и подобрать программное обеспечение, которое подойдет для вашего предприятия. Так как существует множество узкоспециализированных отраслевых решений 1С. Например: 1С: Колледж, 1С:Предприятие 8. Мясокомбинат, 1С:Предприятие 8. Хлебобулочное и кондитерское производство и т.д. Не на всех предприятиях имеет смысл вместо типовой поставки 1С использовать отраслевое решение. В каждом отдельном случае необходим анализ потребностей заказчика и сопоставление с тем или иным программным продуктом.
Лучшая презентация, это презентация на данных вашего предприятия, с вашими нюансами работы, и с цифрами максимально приближенными к реальным.
Что такое проект автоматизации?
Руководство предприятия дало добро на проведение обследования и написания проекта автоматизации. Для начала, необходимо заранее согласовать с исполнителем, что будет в себе содержать проект. Некоторые обязательные реквизиты проекта:
Цели. Цели проекта должны быть составлены согласно правил, описанных выше. Цель должна быть четко описанной, одинаково пониматься исполнителем и заказчиком и решаться средствами автоматизации. У основной цели могут быть дополнительные цели. Например чтобы реализовать цель: «Прослеживаемость партий покупных ТМЦ и собственных полуфабрикатов в составе готовой продукции», нам необходимо автоматизировать складскую логистику (Закупка ТМЦ, отгрузка ГП), производственную логистику (Списание партий покупных ТМЦ и партий собственных полуфабрикатов, на партии готовой продукции), хранение истории производства партий, обеспечение условий противоборствующих возникновению пересортицы по партиям.
Описание бизнес процессов предприятия. В данном разделе должны описываться бизнес процессы до автоматизации и после, я, например, предпочитаю описывать только те процессы, которые будут автоматизироваться и их работу после автоматизации (для экономии собственного времени и бюджета заказчика). В описании бизнес процессов очень удобно использовать графические схемы, которые будут одинаковы, понятны как для заказчика, так и для исполнителя.
Расчет стоимости внедрения. План работ, которые необходимо выполнить, для достижения поставленных целей, чем подробнее план тем, лучше исполнитель понимает свою задачу и точнее произведена оценка стоимости. Если, например, в плане есть пункт «автоматизация складской логистики» и напротив него стоимость, то это говорит о неглубоком анализе со стороны исполнителя. Так как непонятно, что там делать писать новую конфигурацию или разработать несколько отчетов, а может подключение пары сканеров штрих кода и т.д. Расчет стоимости должен показать окончательный бюджет внедрения, разложенный по пунктам.
Определить точную стоимость внедрения очень тяжело особенно на крупных предприятиях, поэтому я в своих проектах закладываю в бюджет примерно от 15 до 20 процентов на всякие непредвиденные работы. Процент, конечно, зависит от сложности и от объема работ, но прямой зависимости нет. Сколько заложить на конкретном проекте обычно подсказывает интуиция и опыт. Но на практике эта статья бюджета всегда пользуется популярностью и расходуется почти полностью. Так что если ваши исполнители выставят в проекте подобную статью, то в ИТ индустрии это нормально и не стоит из-за этого спорить.
За кем следить?
В ходе составления проектной документации, исполнитель будет, проводит совещания с заказчиком, расспрашивать про организацию бизнес процессов и предлагать решения. Если не хотите заработать +1 к проблемам на проекте, советую рассказывать все на чистоту, даже если где-то есть черный учет, выложить это лучше сразу и в деталях. Иначе исполнитель может увеличить стоимость внедрения на 30-50%, как только узнает о новых нюансах. А вам рано или поздно придется рассказать.
Пример из жизни, как делать нельзя. На одном из проектов автоматизации стояла задача по планированию переналадок и выпусков на производственных линиях. Мы провели с заказчиком ряд совещаний, на которых мастера и начальник цеха, рассказывали о том, как они планируют и какие при этом встречаются трудности, как их решать. Моя задача, собрать информацию и переложить алгоритм планирования из головы производственника, на плечи 1С. Всего линий было две, каждая из линий имела свои особенности, и один вид продукции выпускался только на одной линии. Собрав информацию, я потратил около недели безостановочной работы на написания алгоритма по планированию. Описал алгоритм и отправил расчеты и формулы заказчику, его все устроило. По приезду к заказчику проводил итоговую презентацию моих расчетов, после чего один из сотрудников клиента (которого я раньше, кстати, и не видел никогда, наверное, он был в отпуске) заявил, что в случае острой необходимости обе линии могут выпускать один вид продукции. Все на него посмотрели и помахали головой. Мои алгоритмы можно было порвать и выкинуть, при таком раскладе надо было начинать работу заново, а делать две работы за одну оплату очень не хочется.
Еще один случай. «А я вам не скажу». На одном предприятии при проектировании блока управление снабжением. Менеджер по закупкам не стал рассказывать о том, как потребность предприятия в комплектующих, превращается в план закупок на месяц. Его понять можно, так как никто кроме этого менеджера по закупкам не мог составить грамотно этот план, и он был незаменимым сотрудником на предприятии. Подобные явления необходимо пресекать руководством заказчика, если конечно заказчик не хочет иметь уязвимое место в своей информационной системе.
Поэтому если на этапе обследования исполнитель, просит организовать совещание с определенным кругом лиц, это необходимо сделать в полном объеме. Если на вашем предприятии есть не бухгалтерские отгрузки и выпуски, об этом стоит проинформировать исполнителя, так как маленький нюанс забытой с вашей стороны, может обернуться большой проблемой при внедрении. Если исполнитель просит надавить на кого – либо из сотрудников заказчика это следует сделать.
Руководитель проекта.
Наша компания при внедрениях обычно использует два руководителя проекта. Один руководитель со стороны заказчика, другой со стороны исполнителя. Если при первой встрече, или до начала обследования исполнитель не предложил заказчику подобрать руководителя проекта из его кадров, то стоит задуматься над компетенцией исполнителя.
Зачем нужен руководитель проекта (РП) со стороны заказчика? Во первых, это основной сотрудник который будет принимать работу у исполнителей (там программисты пришли, они, там что то делают, сам не знаю что но вроде работают. Вот счета), и координировать работу своих сотрудников (Программист попросил Иванова забить остатки по ТМЦ. А Иванов забил на программиста). Самое главное, оказывать управляющее воздействие на своих сотрудников предприятия. РП заказчика должен с головой погрузиться в проект автоматизации и ставить его на первое место, ну или, в крайнем случае (самом крайнем), на второе. Понимать что там, делают программисты, а главное зачем. РП заказчика должен быть технически «подкованным», понимать работу собственного предприятия и дружить с ИТ технологиями, быть экономически грамотным, ну и самое важное быть руководителем и принимать стратегические решения по проекту.
Большинство рядовых пользователей «в штыки» встречают какую либо автоматизацию, так как, по их мнению, это дополнительная работа, тотальный контроль над их работой, исчезают возможности по хищению, превращают сотрудников из незаменимых, в простую рабочую силу. Подобные ситуации достаточно часто встречаются, когда рядовые менеджеры по продажам или кладовщики начинаю «втыкать палки в колеса». Здесь и необходим РП заказчика, который может «поругаться» и заставить работать людей, так как этого требует ситуация. На должности РП обычно хорошо подходят такие сотрудники как: коммерческий директор, финансовый директор, директор по производству.
Отсутствие руководителя проекта со стороны заказчика, либо не выполнение им своих обязанностей. Приводит к тому, что исполнитель оказывается один на один с проблемами клиента. Идем, например, с вопросом в гл. бухгалтеру, он нас отправляет и говорит, что его это не касается, дальше к экономистам, они нас посылают к логистам, а те говорят, что не имею полномочий для решения вопроса. Вопрос есть, а решать некому.
Руководитель проекта со стороны исполнителя, это человек который координирует работу всего проекта, разрабатывает стратегические и методологические решения, организовывает работу группы специалистов у заказчика, знает сильные и слабые стороны программного продукта, который внедряет и схему работы всей будущей системы.
Главная задача обоих руководителей, следит за качеством выполнения работ. И если одна из сторон начинает уходить в сторону от поставленных целей, до другая должна подправить. Хорошая привычка на проектах автоматизации проведение совещаний между заказчиком и исполнителем, как минимум один раз в неделю. Даже если не о чем рассказывать, то просто встретиться и сказать что все хорошо. Я на подобные совещания помимо руководителя проекта обычно приглашаю руководителей всех структурных подразделений участвующих во внедрении. Еще одна хорошая привычка на проектах автоматизации ведение on-line протокола об ошибках, на крупных предприятия возникает огромное множество вопросов и доработок которые необходимо решить. Обычно все это происходит через электронную почту, но можно и организовать, например через Google calendar, кидать туда вопросы со сроком давности и отмечать выполненные работы.
Что такое Автоматизированная Система Управления Предприятием (АСУП)?
Из официального определения: «комплекс программных, технических, информационных, лингвистических, организационно-технологических средств и действий квалифицированного персонала, предназначенный для решения задач планирования и управления различными видами деятельности предприятия».
АСУП это цель, к которой стремиться ваше предприятие, основная задача внедрения это создание Автоматизированной Системы Управления Предприятием. Хочу сделать акцент что это, во первых, автоматизированная, а не ручная. Во вторых, система, а не просто программа. В третьих система управления, а не учета. А в четвертых предприятием, а не бухгалтерским учетом. Делаю акцент на всех этих словах, потому что очень часто видел как РПБУ (ручная программа бухгалтерского учета) называют АСУПом. РПБУ получается очень часто, когда заказчик начинает очень сильно экономить на внедрении, и не позволяет тем самым создать АСУП. В результате получается, что основная задача программы наподобие УПП, это бухгалтерский учет, в котором на 95% все ведется в ручную.
Определимся из чего состоит АСУП.
Это сама программа, например, на базе 1С, например Управление Производственным Предприятием или Комплексная Автоматизация. Может быть ряд программных средств, которые накладываются друг на друга. Как говорилось выше главное, чтобы программа максимально подходило под требования автоматизации.
Аппаратное обеспечение. Сервер рабочие станции пользователей, локальная сеть, сканеры ШК и т.д. Все железо необходимое для качественной работы программы.
Регламент. Основное понятие, которое превращает программу в систему. Регламент, разработанный совместно с исполнителем и заказчиком определяет, как работать в автоматизированной системе, что бы пользователи разных служб и подразделений работали совместно, а не каждый сам за себя.
Квалифицированный персонал. Главное слово здесь квалифицированный, то есть персонал, который умеет работать в этой автоматизированной системе, в соответствии со своими должностными обязанностями и регламентом.
Автоматизированные функции. Еще один критерий, который необходим для АСУП. Что бы выполняемые функций, в системе не требовали слишком большого объема времени от пользователя, и не превращали его работу в бесконечное забивание данных.
Только наличие всех вышеперечисленных составляющих обеспечит вашему предприятию качественную и бесперебойную работу. Отсутствие хотя бы одной из них приведет разрушению АСУП до уровня РПБУ.
Когда закончиться внедрение??
Если не будете относиться к данному проекту серьезно, то никогда. Вообще у внедрения должны быть установлены сроки, которые конечно могут переноситься при наличии каких либо весомых аргументов. Но сроков необходимо максимально придерживаться. Основная задача, как исполнителя, так и заказчика, это держать себя в тонусе и успеть реализовать задуманное за отведенный на это срок. Конечно, бывает очень неприятно, когда заказчик в послании дни проекта вспоминает, а вот у меня еще есть такая задача, и я без неё жить не могу. Извините дорогой заказчик. Но надо было думать раньше, а не в последний момент вспоминать.
Реализация поставленных целей, так же говорит нам о завершении проекта. Даже если цель реализована на 80 % (имеется ввиду, когда мы можем цель измерить), это уже хороший результат. Когда цель не достигнута, а исполнитель говорить, что внедрение закончено, то здесь следует разобраться. На самом деле задача исполнителя, предоставить инструмент для работы, и обучить им пользоваться. Ну а если заказчик не пользуется предоставленным инструментом или пользуется, но не правильно, то вины исполнителей тут нет. Необходимо принимать меры, что бы ваши сотрудники использовали функционал, согласно регламента, который предоставили вам исполнители.
Внедрение закончиться когда все заработает??? Если честно то нет, на протяжении всей жизни вашей АСУП от внедрения, до перехода на новую систему, у вас будут появляться желания что то доработать или сформировать новый отчет. Так что это нормально. И это уже не внедрение, а сопровождение.
Опубликовал Дмитрий Макаров (pro-rok) в раздел Управление - Управление проектом
Как внедрять будем.
Статья для руководителей организаций планирующих внедрение на своем предприятии 1С. Описаны первые шаги заказчика к Автоматизированной Системе управления Предприятием. Статья написана руководителем проектов по внедрению 1С, основана на собственном опыте внедрений. При необдуманном подходе к внедрению, этот процесс превращается в головную боль для заказчика и станок по сжиганию денег. В данной статье описал, какие ошибки допускаются внедренцами и заказчиками, и как избежать больших финансовых вложений в собственную головную боль. В основном речь идет о внедрении конфигураций на уровне УПП и КА.
В данной статье хочу написать, какие ошибки допускаются внедренцами и заказчиками, и как избежать больших финансовых вложений в собственную головную боль. В основном речь идет о внедрении конфигураций на уровне УПП и КА. Так как, например внедрение 1С: Бухгалтерия по большому счету и не требует самого внедрения. Хотя в моей практике был случай, когда мы писали проект под внедрение БП, но в этом на самом деле была необходимость. И так …
Переходить будем ???
Во первых, решение о том, что в учете необходимо что то менять, должно приниматься клиентом для начала самостоятельно, а только потом необходимо обращаться за консультациями в компании занимающиеся внедрением 1С. Данное решение может принять, например ген. Директор совместно гл. бухгалтером, ну и, например коммерческим директором или техническим директором, если такие есть. Основная причина это: переход на новую учетную программу или регистрация организации.
С регистрацией нового предприятия все понятно, тут мы начинаем с чистого листа и необходимо вести, где то учет. Но если у кого то из руководителей возникает желание перейти на новую учетную систему, например с БП на КА, то стоит задуматься, а нужно ли? Если «старая» учетная система себя оправдывает, работает стабильно и не существует проблем, и она устраивает на 100%, то возможно и не стоит трогать то, что хорошо работает. Ну а если, например Ваша система устарела как 7.7 или есть определенные сложности, проблемы в ведении учета, то стоит задуматься о переходе. Кстати при принятии подобных решений было бы неплохо проконсультироваться со своим рядовыми сотрудниками: менеджеры, мастера, логисты и т.д. Подобные люди дают наиболее красочное представление о работе предприятия, чем их руководители.
Я сам на обследованиях предприятий много раз слышал от руководителей о том, что их все устраивает и вообще жизнь замечательна. Но пообщавшись с работниками склада, менеджерами по продажам понимаешь, что руководители живут в иллюзиях, а сама работа происходит на местах и именно, там существуют проблемы, которые в последствии могут вылиться неадекватной отчетностью для руководителя, на основании которых ОН примет неадекватное решение, или что хуже всего вообще ничего не предпримет. Потому что у нас как всегда все хорошо!
А нужно ли внедрение???
И так вы на своем предприятий приняли решение, что необходимо, что то менять, так как бизнес в современном мире очень динамичен, и, отстав сегодня на пол шага, завтра окажешься на обочине. В первую очередь, о чем стоит задуматься заказчику, а действительно ли на его предприятии необходимо внедрение. Или же можно обойтись просто установкой.
Например, приобретаем программу, зазываем экспресс обучение и перенос остатков. Далее небольшое сопровождение на первые пару месяцев по 20 часов или и того меньше. Ну и все, следом идет ежемесячная установка обновлений и консультации по мере необходимости. Такой сценарий развития событий подойдет, если вы планируете работать на БП, УТ, ЗУП.
Это внедрением назвать тяжело, хотя и можно. Но это не внедрение в нашем понимании. Будем это называть «Экспресс Внедрение». Как можно определить нужно ли предприятию полноценное большое, ДОРОГОЕ внедрение или экспресс внедрение? Конечно, все захотят экспресс внедрение, это быстро и дешево. Но не будем забывать, что наша задача не нажить себе головной боли и не заплатить потом (после «какого-то» внедрения) еще больше, но только за то что бы все более, менее заработало. Задача любого предприятия получение прибыли с наименьшими затратами, поэтому стоит оценить затраты до первого шага.
Один из критериев большого внедрения: объем документооборота, например, ваша организация ежедневно производит на свет по более 60 документов. Это плюс в сторону внедрения ну так скажем не большой.
Следующий не менее важный критерий - сложность учета. У меня был опыт когда я разрабатывал проект, на который потратил пару месяцев, проект был по внедрению БП. Казалось бы куда проще. Но там была своя изюминка это специфика работы (СТО + авто магазин). Были большие сложности в учете НДС и совместном использовании ОСНО + ЕНВД. Информация сливалась в БП из других программ, и наша задача была максимально упростить бухгалтерский учет на предприятии и плюсом сделать его мобильным. Что бы при любом изменении схемы документооборота на предприятии, можно было быстро (с помощью настроек, а не программирования) изменить схему загрузки данных в БП.
Третий не менее важный критерий, это количество сотрудников предприятия занятых в создании первичных документов. На многих небольших предприятиях оформлением первичных бухгалтерских документов занимается непосредственно бухгалтерия, это конечно хорошо, если они справляются с собственными задачами, но при некотором объеме документооборота бухгалтерия начинает максимально упрощать собственный документооборот, так как не успевает делать это оперативно. Например, вместо ежедневного списания ТМЦ, оформляется раз в месяц по каким-то запискам. В результате получаем не оперативный учет, а «посмертный», которым управлять собственно и невозможно, только наблюдать за ним. Поэтому намного упрощает жизнь, когда оформление первичных документов делегируется на других сотрудников, например кладовщиков и менеджеров по продажам. Соответственно, если в вашей цепочке документов учувствует как минимум 3-4 звена (например: кладовщик – приход/расход ТМЦ, менеджер по продажам – заказы покупателям, бухгалтерия – платежи, и т.д.), то для работы этих сотрудников необходима СИСТЕМА и РЕГЛАМЕНТ работы. Что в свою очередь вас подталкивает на внедрение.
Четвертый САМЫЙ ВАЖНЫЙ. На предприятии есть проблемы: например воровство, сложность в организации поставок/отгрузок, хаос в учете и остатках и т.д. Тогда внедряемся.
Цели!!!
Целеполагание является одним из самых важных этапов внедрения, я бы даже сказал: «наиважнейшем». Так как сами понимаете, что если двигаться в никуда, то никуда и не придешь. Основная задача заказчика, точно понимать: «Что он хочет получить от внедрения». Соответственно, как сформировать грамотную цель для проекта внедрения???
Ваша цель должна находиться ЗА рамками 1С. Когда приходишь к заказчику часто слышишь фразы наподобие: «Чтоб все работало», «Чтоб не тормозило», «Что бы было много аналитики», «формировать пачку документов в программе понажатии на одну кнопку» и т.д. Это не цели, это «хотелки». Повторюсь, настоящая цель внедрения находиться в бизнесе, за рамками 1С.
Разберем пример основной цели одного из внедрений - «Увеличение пропускной способности в отделе продаж», но стоит оговориться, что без увеличения штата отдела продаж. Задача в следующем в отдел продаж звонит большое количество клиентов, и отдел продаж не справляется. Очень подходящая цель решаемая средствами автоматизации. Для решения задачи необходим комплекс мер, это работа производства, в режиме on-line, оперативное информирование отдела продаж и т.д. К этому можно добавить личный кабинет в интернете для постоянных клиентов.
Как было раньше, клиент звонит в отдел продаж «Как там мой заказ № 123». После чего менеджер звонит в производство и спрашивает «Что с заказом № 123». Получает ответ, и перезванивает клиенту, сообщая о результатах разговора с цехом. На что тратилось большое количество времени.
Как стало сейчас. Клиент звонит и говорит номер заказа, менеджер набирает номер в своей программе и получает полную информацию по интересующему заказу, может не вешая трубки проинформировать клиента. При необходимости скорректировать дату производства и моментально получить ответ от программы о возможности подобной корректировке. Наличие подобной информации в режиме on-line позволяет организовать личный кабинет клиентов, и получать информацию не беспокоя менеджеров по продажам.
Хорошую цель можно измерить. Идеальная задача, это задача, которую можно измерить до внедрения и после. Если вернемся к нашему примеру, то соответственно можно измерить количество звонков и среднюю продолжительность одного звонка. По итогам внедрения можно увидеть, что количество звонков за рабочий день увеличивается, а длительность соответственно уменьшается. Если к этому количеству прибавить заходы в интернет кабинет по длительности звонка 0 минут, так как не тратиться время менеджера, то получаем результат в увеличении пропускной способности отдела продаж на хороший процент.
Хорошую цель можно, а скорее нужно пересчитать в рублях. Например, можно оценить, сколько потребуется вложений в организацию одного дополнительного рабочего места это: телефонный номер, компьютер, стол, ежемесячная зарплата нового сотрудника, отчисления с ФОТ, расширение офисных помещений и т.д. С противоположной стороны будет стоимость внедрения 1С. Так же примерно просчитать количество клиентов, которых сможет обслужить один менеджер до автоматизации и после. Проект автоматизации бизнеса необходимо рассматривать с точки зрения прибыльности, а не убыточности. И соответственно ставить цели, которые помогут сэкономить: на фонде оплаты труда, офисных помещениях, на более выгодных закупках и т.д., которые, помогут увеличить приток клиентов и уменьшить себестоимость товаров, повысить оборачиваемость капитала.
Основные вопросы на которые должны отвечать ваши цели: как это поможет увеличить прибыль предприятия, как это поможет снизить затраты предприятия, либо избежать дополнительных расходов в будущем, и как это поможет увеличить управляемость предприятия.
Примеры целей:
Пресечение экономически не прибыльных закупок (не слишком маленьких (из-за отсутствия скидок и не оптимальной транспортной логистики) и не слишком большой (для недопущения перегрузки склада на длительный период и переплаты за владение капиталом)).
Оптимизация раскроя материала в производстве. Уменьшения возвратных отходов.
Управление качеством продукта (контроль над производственным процессом, материально-трудовой контроль, контроль выходной продукции).
Сбор или пересбор заказов. Управление резервами. Система автоматическогопере резервирования при получении более срочных заказов.
На самом деле сформировать «красивую» цель для конкретного проекта автоматизации задача достаточно сложная, и не решается в один миг. Поэтому перед встречей с командой внедрения не обязательно знать свои цели досконально, достаточно просто иметь приблизительное представление о своих желаниях по автоматизации. А руководитель проекта автоматизации поможет сформировать окончательную цель и разработает план по её воплощении в жизнь. Но сама идея должна исходить от заказчика, так как лучше самого заказчика, никто не знает его бизнес, и процессы, происходящие внутри компании. Руководитель проекта внедрения лишь придает нужную форму идеям заказчика, используя свой опыт внедрения на других предприятиях.
Первая встреча.
Итак, вы решили внедряться. У вас есть предпосылки для внедрения, вы имеете идеи, которые хотите воплотить в жизнь в ходе проекта автоматизации. Пора обращаться к франчайзи 1С. Для начала Вам, конечно, необходимо купить саму программу 1С. И позвонив во франчайзи, первым делом попадаете на менеджера по продажам. Вариантов развития событий множество в зависимости от грамотности менеджера и его добросовестности. Поэтому рассмотрим несколько вариантов.
Самый худший вариант развития событий. Менеджер предложит Вам организовать встречу. Приехав на ваше предприятие, будет рассказывать какую хорошую программу он вам продает, показывать слайды, отзывы и листовки, уверять, что все будет работать замечательно внедрение не дорогое и достаточно быстрое. НЕ ВЕРТЕ ЕМУ. Главная задача менеджера по продажам ПРОДАТЬ. А внедрением будет заниматься другой человек и это будет головная боль другого человека и заказчика. После продажи, к Вам приедет программист, который будет заниматься внедрением на вашем предприятии. Возможно, у него возникнет мысль о том, что клиенту продали совсем не то, что ему нужно и продали лишь бы продать. Но он вам об этом НЕ СКАЖЕТ, так как нехорошо подставлять компанию, в которой работаешь. И программист будет работать с тем, что продали. +1 к головной боли.
Второй вариант развития событий. Менеджер приезжает к заказчику совместно с программистом. Программист проводи для вас демонстрацию работоспобности и функционала программы. Он будет вам показывать как организованны закупки, продажи, планирование, производство и т.д. Хочу заметить, что он приедет к вам с готовой базой для демонстрации. Уверяю, на ней будет работать ВСЕ. Эта база специально предназначена для демонстрации, данные в базе и решаемые в ней задачи идеально подобранны друг к другу. В реальной жизни такое редко встречается.
В моей практике был случай, когда клиент выбирал франчази и устроил тендер на внедрение. В тендере учувствовали две компании (наша и еще одна). Обе компании проводили презентации программы. В результате, презентация конкурентов понравилось больше, чем наша презентация. И они согласились купить, но внедряться стали у нас (цены наверно понравились). Когда мы дошли до внедрения планирования, я рассчитал стоимость внедрения данного блока. Заказчику это очень не понравилось, из-за большой суммы внедрения. Сумма и сроки ввели в заблуждение заказчика, так как на презентации наши конкуренты показали, как легко и быстро можно пройти от плана продаж, до посменной загрузке оборудования в производстве (конечно, показывали на своей демонстрационной базе). А на самом деле в работе заказчика встречался ряд нюансов, которые было необходимо учесть, при планировании. В результате путь от плана продаж до плана производства оказался достаточно тяжелым, долгим и не обеспечивал 100% точность конечного результата. Альтернативой было доработка типового функционала, которая требовала времени и финансовых вложений. В результате смотреть презентацию функционала программы, конечно, стоит, но относиться к этому необходимо скептически.
Идеальный вариант развития событий. Когда проводиться презентации для заказчика, для общего понимания работы системы. Следом исполнитель предложит заказчику провести обследование предприятия. Порезультатом обследования можно будет провести оценку стоимость внедрения и подобрать программное обеспечение, которое подойдет для вашего предприятия. Так как существует множество узкоспециализированных отраслевых решений 1С. Например: 1С: Колледж, 1С:Предприятие 8. Мясокомбинат, 1С:Предприятие 8. Хлебобулочное и кондитерское производство и т.д. Не на всех предприятиях имеет смысл вместо типовой поставки 1С использовать отраслевое решение. В каждом отдельном случае необходим анализ потребностей заказчика и сопоставление с тем или иным программным продуктом.
Лучшая презентация, это презентация на данных вашего предприятия, с вашими нюансами работы, и с цифрами максимально приближенными к реальным.
Что такое проект автоматизации?
Руководство предприятия дало добро на проведение обследования и написания проекта автоматизации. Для начала, необходимо заранее согласовать с исполнителем, что будет в себе содержать проект. Некоторые обязательные реквизиты проекта:
Цели. Цели проекта должны быть составлены согласно правил, описанных выше. Цель должна быть четко описанной, одинаково пониматься исполнителем и заказчиком и решаться средствами автоматизации. У основной цели могут быть дополнительные цели. Например чтобы реализовать цель: «Прослеживаемость партий покупных ТМЦ и собственных полуфабрикатов в составе готовой продукции», нам необходимо автоматизировать складскую логистику (Закупка ТМЦ, отгрузка ГП), производственную логистику (Списание партий покупных ТМЦ и партий собственных полуфабрикатов, на партии готовой продукции), хранение истории производства партий, обеспечение условий противоборствующих возникновению пересортицы по партиям.
Описание бизнес процессов предприятия. В данном разделе должны описываться бизнес процессы до автоматизации и после, я, например, предпочитаю описывать только те процессы, которые будут автоматизироваться и их работу после автоматизации (для экономии собственного времени и бюджета заказчика). В описании бизнес процессов очень удобно использовать графические схемы, которые будут одинаковы, понятны как для заказчика, так и для исполнителя.
Расчет стоимости внедрения. План работ, которые необходимо выполнить, для достижения поставленных целей, чем подробнее план тем, лучше исполнитель понимает свою задачу и точнее произведена оценка стоимости. Если, например, в плане есть пункт «автоматизация складской логистики» и напротив него стоимость, то это говорит о неглубоком анализе со стороны исполнителя. Так как непонятно, что там делать писать новую конфигурацию или разработать несколько отчетов, а может подключение пары сканеров штрих кода и т.д. Расчет стоимости должен показать окончательный бюджет внедрения, разложенный по пунктам.
Определить точную стоимость внедрения очень тяжело особенно на крупных предприятиях, поэтому я в своих проектах закладываю в бюджет примерно от 15 до 20 процентов на всякие непредвиденные работы. Процент, конечно, зависит от сложности и от объема работ, но прямой зависимости нет. Сколько заложить на конкретном проекте обычно подсказывает интуиция и опыт. Но на практике эта статья бюджета всегда пользуется популярностью и расходуется почти полностью. Так что если ваши исполнители выставят в проекте подобную статью, то в ИТ индустрии это нормально и не стоит из-за этого спорить.
За кем следить?
В ходе составления проектной документации, исполнитель будет, проводит совещания с заказчиком, расспрашивать про организацию бизнес процессов и предлагать решения. Если не хотите заработать +1 к проблемам на проекте, советую рассказывать все на чистоту, даже если где-то есть черный учет, выложить это лучше сразу и в деталях. Иначе исполнитель может увеличить стоимость внедрения на 30-50%, как только узнает о новых нюансах. А вам рано или поздно придется рассказать.
Пример из жизни, как делать нельзя. На одном из проектов автоматизации стояла задача по планированию переналадок и выпусков на производственных линиях. Мы провели с заказчиком ряд совещаний, на которых мастера и начальник цеха, рассказывали о том, как они планируют и какие при этом встречаются трудности, как их решать. Моя задача, собрать информацию и переложить алгоритм планирования из головы производственника, на плечи 1С. Всего линий было две, каждая из линий имела свои особенности, и один вид продукции выпускался только на одной линии. Собрав информацию, я потратил около недели безостановочной работы на написания алгоритма по планированию. Описал алгоритм и отправил расчеты и формулы заказчику, его все устроило. По приезду к заказчику проводил итоговую презентацию моих расчетов, после чего один из сотрудников клиента (которого я раньше, кстати, и не видел никогда, наверное, он был в отпуске) заявил, что в случае острой необходимости обе линии могут выпускать один вид продукции. Все на него посмотрели и помахали головой. Мои алгоритмы можно было порвать и выкинуть, при таком раскладе надо было начинать работу заново, а делать две работы за одну оплату очень не хочется.
Еще один случай. «А я вам не скажу». На одном предприятии при проектировании блока управление снабжением. Менеджер по закупкам не стал рассказывать о том, как потребность предприятия в комплектующих, превращается в план закупок на месяц. Его понять можно, так как никто кроме этого менеджера по закупкам не мог составить грамотно этот план, и он был незаменимым сотрудником на предприятии. Подобные явления необходимо пресекать руководством заказчика, если конечно заказчик не хочет иметь уязвимое место в своей информационной системе.
Поэтому если на этапе обследования исполнитель, просит организовать совещание с определенным кругом лиц, это необходимо сделать в полном объеме. Если на вашем предприятии есть не бухгалтерские отгрузки и выпуски, об этом стоит проинформировать исполнителя, так как маленький нюанс забытой с вашей стороны, может обернуться большой проблемой при внедрении. Если исполнитель просит надавить на кого – либо из сотрудников заказчика это следует сделать.
Руководитель проекта.
Наша компания при внедрениях обычно использует два руководителя проекта. Один руководитель со стороны заказчика, другой со стороны исполнителя. Если при первой встрече, или до начала обследования исполнитель не предложил заказчику подобрать руководителя проекта из его кадров, то стоит задуматься над компетенцией исполнителя.
Зачем нужен руководитель проекта (РП) со стороны заказчика? Во первых, это основной сотрудник который будет принимать работу у исполнителей (там программисты пришли, они, там что то делают, сам не знаю что но вроде работают. Вот счета), и координировать работу своих сотрудников (Программист попросил Иванова забить остатки по ТМЦ. А Иванов забил на программиста). Самое главное, оказывать управляющее воздействие на своих сотрудников предприятия. РП заказчика должен с головой погрузиться в проект автоматизации и ставить его на первое место, ну или, в крайнем случае (самом крайнем), на второе. Понимать что там, делают программисты, а главное зачем. РП заказчика должен быть технически «подкованным», понимать работу собственного предприятия и дружить с ИТ технологиями, быть экономически грамотным, ну и самое важное быть руководителем и принимать стратегические решения по проекту.
Большинство рядовых пользователей «в штыки» встречают какую либо автоматизацию, так как, по их мнению, это дополнительная работа, тотальный контроль над их работой, исчезают возможности по хищению, превращают сотрудников из незаменимых, в простую рабочую силу. Подобные ситуации достаточно часто встречаются, когда рядовые менеджеры по продажам или кладовщики начинаю «втыкать палки в колеса». Здесь и необходим РП заказчика, который может «поругаться» и заставить работать людей, так как этого требует ситуация. На должности РП обычно хорошо подходят такие сотрудники как: коммерческий директор, финансовый директор, директор по производству.
Отсутствие руководителя проекта со стороны заказчика, либо не выполнение им своих обязанностей. Приводит к тому, что исполнитель оказывается один на один с проблемами клиента. Идем, например, с вопросом в гл. бухгалтеру, он нас отправляет и говорит, что его это не касается, дальше к экономистам, они нас посылают к логистам, а те говорят, что не имею полномочий для решения вопроса. Вопрос есть, а решать некому.
Руководитель проекта со стороны исполнителя, это человек который координирует работу всего проекта, разрабатывает стратегические и методологические решения, организовывает работу группы специалистов у заказчика, знает сильные и слабые стороны программного продукта, который внедряет и схему работы всей будущей системы.
Главная задача обоих руководителей, следит за качеством выполнения работ. И если одна из сторон начинает уходить в сторону от поставленных целей, до другая должна подправить. Хорошая привычка на проектах автоматизации проведение совещаний между заказчиком и исполнителем, как минимум один раз в неделю. Даже если не о чем рассказывать, то просто встретиться и сказать что все хорошо. Я на подобные совещания помимо руководителя проекта обычно приглашаю руководителей всех структурных подразделений участвующих во внедрении. Еще одна хорошая привычка на проектах автоматизации ведение on-line протокола об ошибках, на крупных предприятия возникает огромное множество вопросов и доработок которые необходимо решить. Обычно все это происходит через электронную почту, но можно и организовать, например через Google calendar, кидать туда вопросы со сроком давности и отмечать выполненные работы.
Что такое Автоматизированная Система Управления Предприятием (АСУП)?
Из официального определения: «комплекс программных, технических, информационных, лингвистических, организационно-технологических средств и действий квалифицированного персонала, предназначенный для решения задач планирования и управления различными видами деятельности предприятия».
АСУП это цель, к которой стремиться ваше предприятие, основная задача внедрения это создание Автоматизированной Системы Управления Предприятием. Хочу сделать акцент что это, во первых, автоматизированная, а не ручная. Во вторых, система, а не просто программа. В третьих система управления, а не учета. А в четвертых предприятием, а не бухгалтерским учетом. Делаю акцент на всех этих словах, потому что очень часто видел как РПБУ (ручная программа бухгалтерского учета) называют АСУПом. РПБУ получается очень часто, когда заказчик начинает очень сильно экономить на внедрении, и не позволяет тем самым создать АСУП. В результате получается, что основная задача программы наподобие УПП, это бухгалтерский учет, в котором на 95% все ведется в ручную.
Определимся из чего состоит АСУП.
Это сама программа, например, на базе 1С, например Управление Производственным Предприятием или Комплексная Автоматизация. Может быть ряд программных средств, которые накладываются друг на друга. Как говорилось выше главное, чтобы программа максимально подходило под требования автоматизации.
Аппаратное обеспечение. Сервер рабочие станции пользователей, локальная сеть, сканеры ШК и т.д. Все железо необходимое для качественной работы программы.
Регламент. Основное понятие, которое превращает программу в систему. Регламент, разработанный совместно с исполнителем и заказчиком определяет, как работать в автоматизированной системе, что бы пользователи разных служб и подразделений работали совместно, а не каждый сам за себя.
Квалифицированный персонал. Главное слово здесь квалифицированный, то есть персонал, который умеет работать в этой автоматизированной системе, в соответствии со своими должностными обязанностями и регламентом.
Автоматизированные функции. Еще один критерий, который необходим для АСУП. Что бы выполняемые функций, в системе не требовали слишком большого объема времени от пользователя, и не превращали его работу в бесконечное забивание данных.
Только наличие всех вышеперечисленных составляющих обеспечит вашему предприятию качественную и бесперебойную работу. Отсутствие хотя бы одной из них приведет разрушению АСУП до уровня РПБУ.
Когда закончиться внедрение??
Если не будете относиться к данному проекту серьезно, то никогда. Вообще у внедрения должны быть установлены сроки, которые конечно могут переноситься при наличии каких либо весомых аргументов. Но сроков необходимо максимально придерживаться. Основная задача, как исполнителя, так и заказчика, это держать себя в тонусе и успеть реализовать задуманное за отведенный на это срок. Конечно, бывает очень неприятно, когда заказчик в послании дни проекта вспоминает, а вот у меня еще есть такая задача, и я без неё жить не могу. Извините дорогой заказчик. Но надо было думать раньше, а не в последний момент вспоминать.
Реализация поставленных целей, так же говорит нам о завершении проекта. Даже если цель реализована на 80 % (имеется ввиду, когда мы можем цель измерить), это уже хороший результат. Когда цель не достигнута, а исполнитель говорить, что внедрение закончено, то здесь следует разобраться. На самом деле задача исполнителя, предоставить инструмент для работы, и обучить им пользоваться. Ну а если заказчик не пользуется предоставленным инструментом или пользуется, но не правильно, то вины исполнителей тут нет. Необходимо принимать меры, что бы ваши сотрудники использовали функционал, согласно регламента, который предоставили вам исполнители.
Внедрение закончиться когда все заработает??? Если честно то нет, на протяжении всей жизни вашей АСУП от внедрения, до перехода на новую систему, у вас будут появляться желания что то доработать или сформировать новый отчет. Так что это нормально. И это уже не внедрение, а сопровождение.
Руководитель проекта - это не профессия
Руководитель проекта - это не профессия. Надо еще работать. взято тут
Опубликовал Борис Балясников (bb1962) в раздел Управление - Управление проектом
Утверждается: ключевая проблема неудачных проектов автоматизации в том что внедрением занимаются программисты. Хотя это задача управленческая. Я берусь доказать ровным счетом
обратное.
Ссылки по теме:
4 ключевые проблемы проектов внедрения 1С Предприятие
Топ 3 причин провала в проектах по внедрению 1С (Менеджеры продолжают навязывать свою точку зрения 27.11.2014)
В ссылке по теме утверждается: "Ключевая проблема (неудачных проектов автоматизации, прим. ББ) в том что внедрением занимаются программисты. Хотя это задача управленческая". Я берусь доказать ровным счетом обратное: ключевая проблема неудачных проектов автоматизации в том, что внедрением занимаются люди, ничего не понимающие в программировании.
Но начну я с отступления, прямого отношения к теме не имеющего, с терминологии. Так сложилось исторически, что программистами стали называть людей, чуть-чуть больше чем рядовые пользователи знающих и умеющих применительно к вычислительной технике, т.е. по сути продвинутых пользователей, которых в лучшем случае можно считать службой поддержки пользователей или консультантами, но никак не программистами. Здесь все просто, программист по определению - человек, создающий программы, и только такой. Придуман был термин для плохих программистов: "кодировщик" или "кодер". Под этим понимают специалиста, программирующего но ничего в предметной области не понимающего. Это тоже не программист. Это такая же нелепость как хирург, умеющий резать и зашивать, но не знающий что именно нужно "отмахнуть" у больного, и нужно ли вообще. Программист, автоматизирующий бухгалтерский учет, это бухгалтер, создающий САПР для схемотехников, это трассировщик печатных плат и т.д.
А вот теперь вернемся к проблемам проектов автоматизации. В статье по ссылке их четыре, по числу нарушенных правил. Первые две правила - это всего лишь организация процесса разработки.
Понятно, что в любом деле нужна элементарная организованность и дисциплина. Любой программист, даже работающий в одиночку, занимается планированием своих работ, устанавливает сроки, контролирует их, даже если все это существует только в его голове, а не в виде документов. Понятно, что если в проекте занято несколько программистов, то подход становится более формальным: регулярные совещания, фиксация планов "на бумаге", "разбор полетов" и т.д. Но не надо организованность и дисциплину выдавать за отдельную профессию. Руководитель проекта - это не профессия, это скорее должность, как командир звена в авиации. Но также как командиром звена может быть только пилот, также и руководителем проекта может быть только программист. Программист может не быть руководителем проекта, если программистов на проекте несколько. Руководитель проекта не может не быть программистом.
Да, не каждый программист способен быть руководителем проекта. Потому что руководитель проекта - это организатор, а это уже не каждому дано. Потому что руководитель проекта - это еще и взаимодействие с заказчиком, т.е. выполнение всевозможных формальностей: заключение договора, принятие работ, согласование претензий, оплата работ и т.д., а это тем более не каждому по силам. Но все-таки главная функция руководителя проекта - постановка задачи, потому что никто другой этого сделать не в состоянии. Заказчик выполнить постановку задачи не может, он может изложить свои "хотелки". Если это сделано в письменном виде и названо техническим заданием (ТЗ) - замечательно, но это не ТЗ. Это описание пожеланий, требований заказчика, его "хотелок", но не ТЗ. ТЗ, т.е. ТЕХНИЧЕСКОЕ задание, может составить только программист. Постановку задачи может выполнить только программист, исполняющий обязанности руководителя проекта, программист, понявший что хочет заказчик, что заказчику на самом деле нужно (уже не то же самое), обобщивший и (!) формализовавший пожелания заказчика.
Пример? Пожалуйста. Типовая конфигурация "1С: Управление торговлей ред.10.3". Типовой отчет по срокам задолженности покупателей на практике показывает неверные данные. Как ставит задачу заказчик: нам нужен другой отчет, правильный. Как ставит задачу грамотный программист - руководитель проекта: нужно изменить алгоритмы работы документов таким образом, чтобы регистр накопления содержал правильные данные и соответственно отчет - правильную информацию. Существующие алгоритмы работы документов сложны, методика работы с документами предъявляет к пользователям невыполнимые требования, поэтому их нужно изменить. Может такую постанову задачи выполнить руководитель проекта - не программист? Никогда.
Я хочу подчеркнуть, что ключевым понятием для вышестоящих абзацев является не ТЗ, а постановка задачи. Именно ошибки в постановке задачи, выполненной некомпетентным руководителем проекта, являются частыми причинами неудач. А в какой форме существует приложение к договору, описывающее содержание работ, в виде ТЗ, или в виде документа, написанного языком пользователя, это дело десятое.
Следующий тезис автора по ссылке - пользователям нужны инструкции, правильные инструкции - решение всех проблем, возникающих на пользовательском уровне. Это миф. А утверждение, что инструкция должна содержать "условия при которых процесс начинает ветвиться и вилять", это уже утопия. Опять пример: может существовать два подхода к процессу обучения игре в шахматы. Первый: объяснить как играть отдельными фигурами и принципы их возможного взаимодействия. Второй: разбирать поведение игрока на примере конкретных позиций. Так вот комбинаций как в шахматах так и при использовании программ автоматизации даже не миллионы - миллиарды. Можно объяснить пользователю, что такое отчет "Оборотно-сальдовая ведомость по счету" (ОСВ), но нельзя описать все возможные случаи его применения. Писать инструкции о том, как получить остатки товаров с помощью ОСВ по счету "41", это идиотизм. Либо пользователь понимает, что ОСВ можно сформировать по любому счету, а остатки по товарам в бухучете - это остатки по счету "41", либо пользователь этого не понимает, но тогда уже ничем помочь нельзя. Все "ветвления" в инструкции не опишешь, и отсутствие у пользователя способности аналитически мыслить инструкцией не заменишь.
Утверждение о том, что инструкции от фирмы "1С" написаны для программистов, конечно же не верно. Видимо, автор ну очень далек от программирования. Инструкций для программистов по типовым конфигурациям фирмы "1С" просто не существует. Есть инструкции (я здесь сознательно использую терминологию моего оппонента) по платформе "1С: Предприятие", но не по конфигурациям. Такой инструкцией могло бы стать например описание системы учета НДС с подробным указанием назначения каждого регистра и поведения его регистраторов. Некоторые наброски подобного описания существуют на дисках ИТС, но не более чем наброски. А вот для пользователей как раз информации предостаточно, и с картинками и без, в том числе на тех же дисках ИТС, на ресурсах интернета, и не только от фирмы "1С". Но где те пользователи, которые это читают?
Программирование - всегда объектно-ориентированное (ООП). Я в данном случае использую термин ООП не в узком, а в широком понимании. Я говорю не о наследственности объектов, а о способе мышления программиста. Все объекты в конфигурации - это объекты из жизни, это процессы. Что такое например документ "Поступление товаров и услуг", а его описание? Это как раз описание процесса поступления материальных ценностей. А если руководитель проекта этого не понимает, если он не умеет объектно-ориентированно мыслить, это то, с чего я начал: такой руководитель проекта - причина заваленного проекта. А руководитель проекта просто как посредник, как сводник - в лучшем случае балласт.
Статья получилась не столько рекомендательной, сколько опровергающей некоторые стереотипы, чему я впрочем рад, мастеров раздавать советы и без меня хватает.
PS: осталось пояснить некоторую странность названия статьи. Если не ошибаюсь, И.Ильфу и Е.Петрову принадлежит фраза: "Любовь к Советской власти - это не профессия. Надо еще работать." Во времена партийно-хозяйственной номенклатуры существовала такая профессия - руководитель. Сегодня руководит колхозом, завтра - авиапромом, послезавтра - пекарней. Результат известен. Не надо повторять ошибки, надо работать.
Опубликовал Борис Балясников (bb1962) в раздел Управление - Управление проектом
Утверждается: ключевая проблема неудачных проектов автоматизации в том что внедрением занимаются программисты. Хотя это задача управленческая. Я берусь доказать ровным счетом
обратное.
Ссылки по теме:
4 ключевые проблемы проектов внедрения 1С Предприятие
Топ 3 причин провала в проектах по внедрению 1С (Менеджеры продолжают навязывать свою точку зрения 27.11.2014)
В ссылке по теме утверждается: "Ключевая проблема (неудачных проектов автоматизации, прим. ББ) в том что внедрением занимаются программисты. Хотя это задача управленческая". Я берусь доказать ровным счетом обратное: ключевая проблема неудачных проектов автоматизации в том, что внедрением занимаются люди, ничего не понимающие в программировании.
Но начну я с отступления, прямого отношения к теме не имеющего, с терминологии. Так сложилось исторически, что программистами стали называть людей, чуть-чуть больше чем рядовые пользователи знающих и умеющих применительно к вычислительной технике, т.е. по сути продвинутых пользователей, которых в лучшем случае можно считать службой поддержки пользователей или консультантами, но никак не программистами. Здесь все просто, программист по определению - человек, создающий программы, и только такой. Придуман был термин для плохих программистов: "кодировщик" или "кодер". Под этим понимают специалиста, программирующего но ничего в предметной области не понимающего. Это тоже не программист. Это такая же нелепость как хирург, умеющий резать и зашивать, но не знающий что именно нужно "отмахнуть" у больного, и нужно ли вообще. Программист, автоматизирующий бухгалтерский учет, это бухгалтер, создающий САПР для схемотехников, это трассировщик печатных плат и т.д.
А вот теперь вернемся к проблемам проектов автоматизации. В статье по ссылке их четыре, по числу нарушенных правил. Первые две правила - это всего лишь организация процесса разработки.
Понятно, что в любом деле нужна элементарная организованность и дисциплина. Любой программист, даже работающий в одиночку, занимается планированием своих работ, устанавливает сроки, контролирует их, даже если все это существует только в его голове, а не в виде документов. Понятно, что если в проекте занято несколько программистов, то подход становится более формальным: регулярные совещания, фиксация планов "на бумаге", "разбор полетов" и т.д. Но не надо организованность и дисциплину выдавать за отдельную профессию. Руководитель проекта - это не профессия, это скорее должность, как командир звена в авиации. Но также как командиром звена может быть только пилот, также и руководителем проекта может быть только программист. Программист может не быть руководителем проекта, если программистов на проекте несколько. Руководитель проекта не может не быть программистом.
Да, не каждый программист способен быть руководителем проекта. Потому что руководитель проекта - это организатор, а это уже не каждому дано. Потому что руководитель проекта - это еще и взаимодействие с заказчиком, т.е. выполнение всевозможных формальностей: заключение договора, принятие работ, согласование претензий, оплата работ и т.д., а это тем более не каждому по силам. Но все-таки главная функция руководителя проекта - постановка задачи, потому что никто другой этого сделать не в состоянии. Заказчик выполнить постановку задачи не может, он может изложить свои "хотелки". Если это сделано в письменном виде и названо техническим заданием (ТЗ) - замечательно, но это не ТЗ. Это описание пожеланий, требований заказчика, его "хотелок", но не ТЗ. ТЗ, т.е. ТЕХНИЧЕСКОЕ задание, может составить только программист. Постановку задачи может выполнить только программист, исполняющий обязанности руководителя проекта, программист, понявший что хочет заказчик, что заказчику на самом деле нужно (уже не то же самое), обобщивший и (!) формализовавший пожелания заказчика.
Пример? Пожалуйста. Типовая конфигурация "1С: Управление торговлей ред.10.3". Типовой отчет по срокам задолженности покупателей на практике показывает неверные данные. Как ставит задачу заказчик: нам нужен другой отчет, правильный. Как ставит задачу грамотный программист - руководитель проекта: нужно изменить алгоритмы работы документов таким образом, чтобы регистр накопления содержал правильные данные и соответственно отчет - правильную информацию. Существующие алгоритмы работы документов сложны, методика работы с документами предъявляет к пользователям невыполнимые требования, поэтому их нужно изменить. Может такую постанову задачи выполнить руководитель проекта - не программист? Никогда.
Я хочу подчеркнуть, что ключевым понятием для вышестоящих абзацев является не ТЗ, а постановка задачи. Именно ошибки в постановке задачи, выполненной некомпетентным руководителем проекта, являются частыми причинами неудач. А в какой форме существует приложение к договору, описывающее содержание работ, в виде ТЗ, или в виде документа, написанного языком пользователя, это дело десятое.
Следующий тезис автора по ссылке - пользователям нужны инструкции, правильные инструкции - решение всех проблем, возникающих на пользовательском уровне. Это миф. А утверждение, что инструкция должна содержать "условия при которых процесс начинает ветвиться и вилять", это уже утопия. Опять пример: может существовать два подхода к процессу обучения игре в шахматы. Первый: объяснить как играть отдельными фигурами и принципы их возможного взаимодействия. Второй: разбирать поведение игрока на примере конкретных позиций. Так вот комбинаций как в шахматах так и при использовании программ автоматизации даже не миллионы - миллиарды. Можно объяснить пользователю, что такое отчет "Оборотно-сальдовая ведомость по счету" (ОСВ), но нельзя описать все возможные случаи его применения. Писать инструкции о том, как получить остатки товаров с помощью ОСВ по счету "41", это идиотизм. Либо пользователь понимает, что ОСВ можно сформировать по любому счету, а остатки по товарам в бухучете - это остатки по счету "41", либо пользователь этого не понимает, но тогда уже ничем помочь нельзя. Все "ветвления" в инструкции не опишешь, и отсутствие у пользователя способности аналитически мыслить инструкцией не заменишь.
Утверждение о том, что инструкции от фирмы "1С" написаны для программистов, конечно же не верно. Видимо, автор ну очень далек от программирования. Инструкций для программистов по типовым конфигурациям фирмы "1С" просто не существует. Есть инструкции (я здесь сознательно использую терминологию моего оппонента) по платформе "1С: Предприятие", но не по конфигурациям. Такой инструкцией могло бы стать например описание системы учета НДС с подробным указанием назначения каждого регистра и поведения его регистраторов. Некоторые наброски подобного описания существуют на дисках ИТС, но не более чем наброски. А вот для пользователей как раз информации предостаточно, и с картинками и без, в том числе на тех же дисках ИТС, на ресурсах интернета, и не только от фирмы "1С". Но где те пользователи, которые это читают?
Программирование - всегда объектно-ориентированное (ООП). Я в данном случае использую термин ООП не в узком, а в широком понимании. Я говорю не о наследственности объектов, а о способе мышления программиста. Все объекты в конфигурации - это объекты из жизни, это процессы. Что такое например документ "Поступление товаров и услуг", а его описание? Это как раз описание процесса поступления материальных ценностей. А если руководитель проекта этого не понимает, если он не умеет объектно-ориентированно мыслить, это то, с чего я начал: такой руководитель проекта - причина заваленного проекта. А руководитель проекта просто как посредник, как сводник - в лучшем случае балласт.
Статья получилась не столько рекомендательной, сколько опровергающей некоторые стереотипы, чему я впрочем рад, мастеров раздавать советы и без меня хватает.
PS: осталось пояснить некоторую странность названия статьи. Если не ошибаюсь, И.Ильфу и Е.Петрову принадлежит фраза: "Любовь к Советской власти - это не профессия. Надо еще работать." Во времена партийно-хозяйственной номенклатуры существовала такая профессия - руководитель. Сегодня руководит колхозом, завтра - авиапромом, послезавтра - пекарней. Результат известен. Не надо повторять ошибки, надо работать.
Как не нужно "запускать" проекты 1С взято тут
Опубликовал Александр Тарасинский (axxell) в раздел Управление - Управление проектом
Карты памяти
Бизнес-процесс "Закупка сырья"
Управление проектом
Диаграмма состояния проекта
Таблица состояния проекта
Проектирование интерфейса
Описываю мою практику работы над проектами совместно с компаниями Франчайзи. И рекомендации по работе с такими проектами.
Предыстория:
Я работаю в достаточно большой Группе компаний, которая занимается и производством и реализацией собственной продукции. Устроился у нас руководитель проектов, которому руководство (самое высокое руководство) дало "зеленый свет" для запуска проектов. Сразу хочу сказать, что он никогда не занимался 1С, был успешный опыт запуска Axapta на нескольких заводах. Позиция нового руководителя была достаточно проста: содержать собственных программистов - дорого и не всегда эффективно, вот нанять компанию, в которой работают профессионалы и запустить быстро проект - вот это дело! И вот на волне этого позитивного заявления стартануло 2 проекта: на заводе и в торговой компании. Для внедрения привлекли не какие-то мелкие компании Франчайзи, а достаточно крупные и известные. Чем это закончилось для нас?
Кому адресована эта статья:
Кому предстоит первый раз работать с Франчайзи и у кого нет пока опыта в запуске больших проектов.
Некоторые уточнения:
Здесь я выражаю свою точку зрения. И смотрю я на эти проекты с позиции Заказчика. Позиция Франчайзи относительно результатов наверняка будет другой. Подключился к этим проектам уже на этапе запуска в эксплуатацию, когда проекты находились в достаточно плачевном состоянии. Имена Франчайзи я не буду называть. Т.к. не всегда важны имена, - а руководители проектов, как со стороны Франчайзи, так и со стороны Заказчика. Указывать компании, в которых запускались проекты тоже не имеет смысла, т.к. любая компания может повторить этот печальный опыт при стечении определенных обстоятельств.
Все гипертекстовые ссылки в этой статье ведут к открытию новых окон, чтобы не помешать чтению.
Проект 1. Внедрение системы управления складом (WMS)
Конфигурация: Управление складом
Срок подготовки проекта к запуску: 2 месяца.
Продолжительность проекта от начала до полноценной работы: 4 месяца.
Особенность проекта: WMS должна была обеспечить работу дистрибуционного и оптового склада с многоярусными стеллажами (5 и 6 уровней).
Какие главные ошибки Франчайзи: не умели работать с быстрооборачиваемыми складами и полагали, что накопленный опыт поможет запустить проект. Была предложена провальная схема работы: учитывала только обработку оптовых заказов. Также схема не соответствовала предоставленным сведениям о входящих, внутренних и исходящих товарных потоках. Не была учтена скорость работы штабелёров паллет. В итоге, предложенная Франчайзи схема работы выглядела так: каждый заказ клиента должен был обрабатываться отдельно и при отсутствии товара на нижнем ярусе необходимо было спускать паллету с верхних ярусов и поднимать обратно если на паллете оставался товар (для высвобождения места для спуска другой паллеты).
Какое решение сработало: организация области отбора товара со своевременной подпиткой с верхних ярусов.
Закончил ли Франчайзи проект: Нет, по причине несостоятельности предложить работающую схему.
Что получил Заказчик после проекта: склад запустили своими силами.
Что получил Франчайзи после проекта: узнал схему, которая была внедрена в новой версии продукта "Управление складом", переманил нашего работника (cтарший оператор WMS), который занимается проектами.
Был бы проект успешно закончен, если бы у Франчайзи было больше времени: Нет. Специально задал этот вопрос руководителю проекта со стороны Франчайзи после того как мы сами запустили проект. У Франчайзи не было такого опыта и специалисты в тот момент не были в состоянии предложить рабочую схему (сейчас уже в состоянии Wink).
Вывод: запускать проекты с Франчайзи, у которых есть опыт запуска аналогичных проектов. Если Франчайзи предлагает референс-визит на предприятие отдалённо похожее на Ваше, не соглашайтесь, ищите другого Франчайзи, у которого есть опыт с предприятими Вашего профиля. И само собой - очень хорошо нужно понимать чего хочешь и требовать выполнения этого от Франчайзи. Как самостоятельно преодолеть пропасть между пониманием и незнанием? Нанять стороннего по отношению к Франчайзи консультанта по предметной области, у которого есть успешный опыт запуска аналогичных проектов. Окупятся ли затраты на такого специалиста? Если четко поставить задачу специалисту - да.
Проект 2. Создание автоматизированной системы по управлению производством
Конфигурация: Управление производственным предприятием
Срок подготовки проекта к запуску Франчайзи: 9 месяцев (у Франчайзи времени было 3 месяца перед первым запуском и 6 месяцев перед вторым запуском).
Продолжительность проекта от начала до реального запуска: 2,5 года.
Особенности проекта. Необходим механизм планирования производства и потребностей в сырье. Движения сырья и готовой продукции должны выполняться в разрезе Серий (т.к. это пищевая промышленность и необходимо отслеживать из чего делается продукция, которую едят покупатели). Требуется постоянно отслеживать себестоимость производимой продукции.
Какие были ошибки Франчайзи: Проблема с качеством подготовки и проработки модели. Проблема с квалификацией программистов. Просчёты с оценкой трудоёмкости ввода документов. Ущербный подход к запуску проекта, когда консультанты приезжают 1 раз в неделю на 1-2 дня (мотивировали тем, что таким образом удешевляются проекты для Заказчиков, т.к. консультанты не просиживают у Заказчика. Теперь представляете какая каша из проектов может быть в голове консультантов).
Какое решение сработало: Поэтапный запуск проекта, а не все сразу: сначала запустили Зарплату, затем движения по складам, и только потом бухгалтерский и производственный учёт. Тщательная проверка абсолютно всех операций и сведение тестового месяца с сопоставленим полученных цифр в предыдущей системе. Ради справедливости стоит отметить, всё-таки удалось с Франчайзи запустить Зарплату (на это у Франчайзи еще хватило сил). И то, мне пришлось поломать схему работы Франчайзи, когда консультант приезжал на 1-2 дня на завод.
Закончил ли Франчайзи проект: Нет, по причине отсутствия кадровых ресурсов для работы над проектом и, вдобавок, прокачал на тот момент 90% бюджета.
Только ли Франчайзи виноват: Нет. Была и проблема с нашей стороны. Пытались автоматизировать неоптимальные бизнес-процессы. После оптимизации бизесс-процессов оказалось, что часть кода программистов Франчайзи можно выкинуть на свалку.
Был бы проект успешно закончен, если бы у Франчайзи было больше времени: Скорее Нет, чем да. Хоть консультанты и обладали хорошими знаниями и программистов можно было бы привлечь уровнем повыше (я не понимаю как можно внедрять коммерческие проекты и размещать в комментариях слово "говнокод" - извините, но так и было; в печатных формах документов прописывать ФИО ответственных, а не брать эти сведения из базы и т.д.). Но у Франчайзи была проблема с подходом к управлению проектами. Так можно запускать только типовые проекты, на которых руководитель проекта и команда уже набила руку.
Вывод: работать с Франчайзи, у которых есть опыт на таких же проектах по специализации и объёму. Не устраивать из проекта головокружительную гонку со сроками. Не покупаться на "космические корабли" в виде запущенного решения по планированию и оптимизации производства, планированию потребностей в сырьё. Сначала нужно организовать отражение фактических операций, а потом уже в космос.
Почему так радужно начинались и так печально закончились совместные с Франчайзи проекты
Думаю, что проблема состояла в разной точке зрения на результат проекта. Заказчик хотел в итоге получить автоматизированную систему, Франчайзи предлагал коробку с доработками. В моём случае пропасть между коробкой УПП и готовым к запуску продуктом Франчайзи не смогли закрыть.
Обобщение опыта или Чего не нужно делать на больших проектах:
Считать, что существует только единственный вариант конфигурации иноформационной базы для проекта.
Рассчитывать, что можно запустить УПП за 3 месяца (даже с учётом того, что Франчайзи обещает нагнать кучу народа). Самое интересное, что этот Франчайзи мне недавно опять предлагал помощь в запуске проекта за 3 месяца.
Побывать на класной презентации Франчайзи и думать, что у Франчайзи невероятная квалификация и все взлетит лёгким движением руки. Невероятная квалификация может быть у руководителя проекта, консультантов, программистов, задействованных на Вашем проекте. Или не на Вашем проекте Wink.
Спешить с заключением договора. Юрист предприятия должен обстоятельно проверить его. Возможно лучший вариант - привлечь стороннего юриста с большим опытом работы с такого рода договорами. Можно себя очень сильно обезопасить от неприятных последствий. Необходимость в качественно проработанном Договоре возникнет, когда проект пойдёт наперекосяк.
Рассчитывать, что некоторые операции "стандартные" и их можно запросто запустить без проверки.
Поверить в опыт Франчайзи (а не проверить).
Предполагать, что обучение преподавателями Франчайзи будет проведено на высоком уровне.
Пытаться запустить проект с помощью сотрудников Заказчика, которые параллельно с проектом выполняют и другую работу.
Предоставить Франчайзи полное право определять сколько времени будут находиться консультанты на объекте.
Полагать, что если в первый раз у Франчайзи не получится запустить проект, то во второй раз - получится.
А теперь на что нужно обратить внимание при запуске или спасении большого проекта
Организация работы руководителя проекта Заказчика
Вы должны заблаговременно освоить необходимые инструменты, которые помогут в запуске проекта. Лично я нашёл удобными для себя такие инструменты:
Карты памяти - позволяют структуировать информацию. Особенно полезны на начальном этапе, когда идёт огромный вал новых сведений. Кроме наглядного представления разрозненных поначалу данных по проекту, позволяют легче запомнить новую информацию. Я использую программный продукт MindManager. Для теоретического освоения инструмента рекомендую изучить книгу Инструменты McKinsey. Лучшая практика решения бизнес-проблем, для практического освоения - книгу Сергея Бехтерева "Майнд-менеджмент. Решение бизнес-задач с помощью интеллект-карт".
Работа над бизнес-процессами. Применяя инструменты построения бизнес-процессов, сэкономите себе и другим участникам проекта вагон времени. Я использую программный продукт BizAgi. Освоить работу с этим продуктом очень просто и здесь поможет сайт компании разработчика.
Инструмент управления проектом. Позволит разделить этапы на задачи и подзадачи с указанием сроков и ответственных. Выбрал для себя RedMine. Кроме MS Project, есть интересные онлайн сервисы Gigantt.com и Tom's planner.
Средство хранения информации по проекту. Позволит предоставить участникам проекта и заинтересованным лицам критически важную информацию. Для меня - это Google Docs.
Инструмент для проектирования интерфейсов. Позволит Вам достичь взаимопонимания с программистами. Удобным для меня стал iPlotz.
Примеры работы инструментов
1. Карты памяти позволили мне разобраться с текущим состоянием дел по проекту и упорядочить необходимые мне сведения.Карты памяти
2. Визуализация бизнес-процессов повышает качество представления информации заинтересованным лицам.Бизнес-процесс
3. RedMine как средство управления проектом позволяет не упустить ни одной мелочи.
Управление проектом
4. Google Docs - очень полезный инструмент для хранения и представления критически важной информации по проектуДиаграмма состояния проекта
Таблица состояния проекта5. Для проектирования интерфейсов есть множество инструментов. Их преимущество заключается в том, что кроме самого интерфейса, можно отобразить данные, а также можно даже создать кликабельные диалоги. Класный способ передать свои пожелания разработчику.Проектирование интерфейса
Перед началом работы с Франчайзи
Рекомендую ознакомиться с курсом ИТРП "Как избежать ошибок на проектах". Это курс даст Вам понимание работы "кухни" Франчайзи: начиная от подготовки документации по проекту и заканчивая информацией чего опасаются Франчайзи. Также Вы сможете лучше понимать мотивы руководителя проекта Франчайзи.
Какое типовое решение выбрать для автоматизации производства?
Очень интересный вопрос. Ведь все знают об УПП. Неужели нужно задуматься над этим вопросом? Оказывается нужно. И очень-очень сильно.
До начала работы над проектом, нужно хорошо понимать характер производства. От этого и нужно отталкиваться.
Есть два типа производственных предприятий: дискретные и процессные. Для каждого типа предназначена своя конфигурация. А вот теперь моё открытие: 1С предлагает для автоматизации 2 продукта. УПП рассматривается для дискретных производств. А вот когда уже функции УПП не удовлетворяют Заказчика и тип производства Заказчика - процессное, предлагается другой продукт. Тоже компании 1С - ИТРП:Процессное производство (1С купила ИТРП несколько лет назад и даже офис ИТРП напротив 1С на Селезнёвской).
В чём разница между дискретным и процессным производством? Сначала приведу примеры. Дискретное производство - машиностроение. Процессное производство - пищевая и химическая промышленость. Правило такое, если готовое изделие можно разобрать на составные части-комплектующие, это дискретное производство, нельзя - процессное производство.
Что это означало в моём случае (пищевая промышленность). Был сделан неверный выбор. Мы начали внедрять не ту конфигурацию! Но тут уже вопрос, у кого будет такая квалификация, чтобы определить поначалу что нужно внедрять? Думаю, что в ИТРП есть такие специалисты. Убедился в этом после беседы с зам. директора компании. Тем более, что ИТРП принимала участие в разработке УПП, да и разрабатывает продукты, дополняющие функциональность УПП.
Работа над проектом УПП
Цели
Любой проект начинается с целей. И Вы должны очень чётко понимать чего нужно достигнуть. Рекомендую почитать интересную статью на Инфостарте посвященную общим принципам внедрения проектов.
Цели должны быть известны до беседы с Франчайзи. В моём случае цели проекта:
Внедрить функции планирования производства и планирования закупок для обеспечения процесса безперебойного производства и сокращения запасов на складах
Обеспечить оперативный ввод в базу хозяйственных операций минута-в-минуту, добиться учёта движения сырья по всем складам на заводе в единой информационной базе с детализацией до Серий номенклатуры
Внедрить оперативный расчёт себестоимости готовой продукции, чтобы отследить рентабельность каждой отгрузки
Выбор Франчайзи для большого проекта
Объективные критерии:
Есть успешный опыт запуска аналогичных проектов. Просмотрите портфель проектов, выберите предприятие и просите организовать референс-визит.
Получите резюме специалистов, которые могут работать с Вашим проектом. Воспринимайте руководителя проекта, консультантов и программистов как специалистов, которых Вы берете на работу. Соответственно и подход должен быть такой же: без резюме и личной беседы можно сделать неверный выбор. Скайп есть у всех и не так уж трудно организовать беседу с ключевыми специалистами. Само собой это нужно делать перед заключением договора.
Оцените качество работы Франчайзи. Если у Вас есть задача, непродолжительная по времени и Вы можете передать её Франчайзи, сделайте это, чтобы проверить работу Франчайзи. Я так сходу отсеял одного Франчайзи.
Судебная практика Франчайзи, узнать причины судебных исков и какие были постановления суда.
Субъективные критерии:
Оцените как представители Франчайзи ведут диалог, как отвечают на вопросы. Смогут ли организовать беседу со специалистом по нужному профилю.
Моя практика. После того, как меня подставил Франчайзи, сообщив, что нет ресурсов для работы над проектом, я разговаривал с тремя другими Франчайзи. И самое интересное, что представители одного Франчайзи (директор и руководитель проектов) вызвали у меня профессиональную симпатию с первой беседы. Они так отвечали на вопросы и задавали их, что сходу просматривался опыт и качественная практика. К сожалению, у меня не получилось полноценно работать с этим Франчайзи, т.к. у них был слишком плотный график запуска проектов на 1 год вперёд. Но они смогли предоставить мне специалистов для работы над отдельными участками. И эта работа была выполнена на высшем уровне.
Какой Вам нужен результат после проведения тендера:
Одна компания, которая будет заниматься внедрением проекта и другая, как резерв.
Моя практика. Оказалось, что компания Франчайзи, с которой я продолжил работу над проектом УПП, участвовала в первоначальном тендере. Предшествущий руководитель проекта отсеял их, т.к. они не обещали "полететь в космос" и сообщили, что срок запуска будет больше.
Самое смешное в моей ситуации то, что стоимость проекта у резервного Франчайзи была в 2 раза ниже, чем у провального Франчайзи (резервный Франчайзи работает на местном рынке 1С). Еще смешнее ситуация, что Франчайзи, который провалил наш проект, до запуска нашего проекта собрал местных Франчайзи и предлагал им продать наш проект за 50% от стоимости Smile с аргументацией, что используют офигенную проектную технологию. Результат будет гарантирован, ну уже внедрением пусть занимается местный Франчайзи.
Поиск Франчайзи
Сайт 1С
Интернет
Знакомые
Поиск внешнего консультанта (если чувствуете недостаток знаний)
Infostart.ru - ищите публикации по Вашей тематике
Nashe1c.ru (аналог Infostart от 1С) - ищите публикации по Вашей тематике
Мой круг - множество резюме специалистов
Рекомендации по заключению и исполнению договора
Какой вид договора заключать? Договор подряда или договор оказания услуг? В книге "Как избежать ошибок на проектах" для Франчайзи рекомендуется заключение договора подряда на все этапы, кроме этапа ввода системы в эксплуатацию - здесь договор оказания услуг. В чём разница между ними? Принципиальная. Именно здесь, при работе над проектом, я и нарвался на проблему. Договор подряда заключается на результат (готовность системы к эксплуатации). А договор оказания услуг - на процесс работы. Т.е., если заключён договор оказания услуг на проект, то Франчайзи за результат никак не отвечает. Руководитель проекта работал? Работал. Программисты работали? Работали. Вот акт, что мы работали. А сможет ли продукт выполнять возложенные функции - не наша проблема.
Мои выводы:
Нужно было заключать договор подряда, а не договор оказания услуг. По договору возможна оплата по каждому этапу с подписанием акта. Но кроме актов на этапы, должен быть еще подписываться акт на результат. Полная оплата договора должна быть после подписания результирующего акта. Это означает, что акты по этапам можете подписывать на полную сумму, но оплачиваются они должны только частично согласно договоренности (например, на 80 или 90 %).
Для этапа функционального моделирования в договоре должен быть указан результат этапа - "функционирующая модель".
Если ТЗ составлял Франчайзи и будете подписывать ТЗ с такой степенью детализации, которую Вы не понимаете, то должна быть оговорка "что подписываемое ТЗ действует в рамках разумности общего пользования".
Любые действия, которые Вы должны выполнить по договору, или Франчайзи должен выполнить по договору, должны подтверждаться письменно с фиксированием ответственности. Где была моя ошибка? С руководителем проекта со стороны Франчайзи был согласован график запуска (первые два запуска прошли без меня и как понимаете - неудачно). В результате, консультант приехал к нам на завод с 1,5 месячным опозданием, а потом и вовсе руководитель проекта Франчайзи заявил, что нет свободных специалистов для работы над проектом.
В договоре должен быть указан пункт о признании юридическую силы электронной переписки.
Поддержка проекта руководством
Первостепенное значение имеет заинтересованность руководства в запуске проекта. И такая заинтересованность должна быть не формальная, а искренняя. Проверить интерес очень просто. Сколько раз у Вас спросят не только как идёт проект, но и захотят узнать детали?
Моя практика. Для меня проект по запуску УПП был открытыем. Такого интереса к проекту со стороны руководства я еще никогда в жизни не видел. Скриншоты Google Docs и BizAgi в этой статье Вы наблюдаете именно благодаря этому интересу, мне пришлось найти удобные инструменты не только для меня, но и для всех участников проекта.
Формирование рабочей группы проекта
Для работы над проектом, нужно сформировать рабочую группу на предприятии. Состав рабочей группы может со временем меняться, но некоторые сотрудники войдут в состав и будут задействованы от начала до конца проекта. Обязательно нужно договориться с руководством, чтобы сотрудники, которые войдут в состав постоянной рабочей группы, были освобождены от выполнения своих оперативных обязанностей. Им необходимо готовить замену.
Моя практика. У меня на проекте таким ключевым сотрудником является Старший экономист. Остальные сотрудники завода привлекалились в рабочую группу для работы над специфическими задачами.
Мотивация участников проекта
Вопрос премирования сотрудников за успешный запуск проекта необходимо решить с руководством до начала работы над проектом. Потому что когда в диалоге с пользователями все доводы могут быть исчерпаны, денежный вопрос может кардинальным образом повлиять на проект. Репрессии не самый лучший способ добиться лояльности по отношении к проекту. Необходимо будет согласовать для каждого сотрудника как размер премии, так и оплату за вынужденные переработки.
Моя практика. Не нужно обманывать себя, запуск проекта это не обычная рабочая нагрузка на работников. Необходимо перед началом проекта на общем собрании объявить участникам о выплате премии за успешный запуск проекта. Кроме возможности за короткий срок выполнить большой объём работы, компенсации пользователям являются инвестицией в практическое обучение по работе с новой системой.
Экспресс-обследование Франчайзи
Для проведения экспресс-обследование заключается отдельный договор. В ходе выполнения Вы присматриваетесь к работе Франчайзи, Франчайзи оценивает проект. Может сложиться такая ситуация, когда Франчайзи Вам не подойдёт, или, наоборот, Франчайзи сообщит, что откажется от проекта. Результат экспресс-обследования - указывается какие участки будут автоматизироваться, какие нужны трудозатраты и предварительная стоимостная оценка проекта. Помните, что не бывает стандартных участков. В УПП специфичныее для производств участки (да и не только для производств, но и для бухгалтерского учёта) не автоматизированы и придётся их доделывать. Если вопрос коснётся изменения внутренних механизмов работы - вот тут Вас могут ожидать проблемы и об этом лучше знать заранее.
Что выбрать РАУЗ или Партионный учёт?
Я так понимаю, что сейчас где-то в 90% компаний использует Расширенную Аналитику Учёта Затрат. Многие восторгаются этим механизмом, т.к. он избавил компании от извечных проблем связанных с вводом документов задним числом, почти избавились от блокировок транзакций. В общем, с РАУЗ жить стало проще. Для нашей компании этот механизм неприемлим. Причин есть несколько, но главная из них - подготовка отчётности по МСФО для передачи в головную компанию. РАУЗ здесь быть не может, этой методики определения стоимости выбытия запасов в МСФО нет. У нас в компании каждый год приезжают аудиторы Ernst&Young с проверкой. И в план проверки отдельным пунктом входит проверка соблюдения ФИФО (У нас в учётной политике предусмотрен этот способ). Механизм проверки очень простой, берется наугад несколько номенклатурных позиций и по ним вручную проверяется движение себестоимости по каждой операции за произвольный месяц года.
Также в РАУЗ меня смущают проблемы в расчете себестоимости при перемещении запасов со склада на склад. Об этом упоминает Игорь Бурьяненко в Продвинутом курсе по учёту производства в УПП.
Моя практика. Где у меня были проблемы с моим с Франчайзи? В модели бухучёта, которую подготовили специалисты Франчайзи, было чётко прописано, что используется Партионный учёт. А сдачу пытались провести по РАУЗ. Смешно Wink. Так и не сдали. Сначала представили как ошибку конфигурации, потом сказали, что мы данные неверно вводили, потом - просто сбежали из-за нехватки ресурсов.
Функциональное моделирование
Ключевая стадия проекта, в которой проводится анализ бизнес-процессов: как есть, как должно быть. Причём особое внимание нужно уделить разделу "как должно быть". Ведь не зря Заказчик начинает проект автоматизации, значит ситуация "как есть" не устраивает. Разработанные бизнес-процессы будут сопоставляться с возможностями типовой конфигурации. Исходя из результатов, будет сформирована оценка проекта. Здесь рабочая группа со стороны Заказчика должна пополниться специалистами, которые отвечают и знают автоматизируемые участки. В этот момент, состав рабочей группы наиполный.
Один нюанс. Для качественной проработки автоматизируемых участков в ситуации "как есть" нужно поработать с самыми компетентными специалистами по участку на предприятии. Руководитель поразделения не всегда располагает большим количеством свободного времени для такой работы. Именно в беседах со специалистами, Вы сможете выявить такие "мелочи", которые для проекта могут оказаться огромными. Для выявления "как должно быть" уже нужна работа с руководителями подразделений. Т.е. функциональное моделирование должно выполняться с участием пользователей будущей системы.
Моя практика. Т.к. я подключился к проекту уже намного позже, то могу предположить, что в состав входили: Финансовый директор, Главный бухгалтер, Главный экономист, Директора по производству и их заместители, Руководители складов, Руководитель логистики. Если говорить о качестве работы Франчайзи, то это такие "мелочи", которые возникнуть могли из-за того, что не было работы с исполнителями:
моделирование Зарплаты - "забыли" предусмотреть создание мехнизма по выгрузке сведений для банка по выплате зарплаты на зарплатные карточки. В результате, 1000 работников завода могло остаться без зарплаты. Пришлось в авральном порядке программисту Франчайзи написать обработку выгрузки. Казалось бы ничтожная по объему работа. Но последствия могли быть очень неприятные.
моделирование бухучёта в части расчета себестоимости - "забыли" предусмотреть механизм распределения общепроизводственных расходов, когда базой распределения является выпуск готовой продукции за предыдущие периоды. Тоже как будто мелочь. Но последствия - расхождения на миллионы рублей в себестоимости.
В итоге - картина маслом - моделирование выполнено формально, для галочки.
Я привёл только некоторые пункты. Чтобы всё рассказать нужно написать отдельную статью.
Что такое технический проект и техническое задание и кто за них отвечает
Техническое задание (далее ТЗ) - это функциональные требования к создаваемому продукту, Технический проект - способ реализации этих требований. Соответственно за техзадание совместная ответственность Заказчика с Франчайзи (или Заказчика, если берет на себя ответственность подготовку ТЗ), за технический проект - Франчайзи. Техзадание может составляться как специалистами Франчайзи, так и Заказчиком (в зависимости от уровня квалификации). Техпроект готовит Франчайзи. Нужно было требовать техпроект для ознакомления.
Крайне важный шаг. От него зависит качество работы системы. Не пропустите его. ТЗ Вы должны идеально понимать.
Также, в случае возникновения спора с Франчайзи и проведения экспертизы в суде - именно по этому документу эксперт и будет делать заключение о полноте выполненных работ.
Моя практика. Какие были ошибки Франчайзи? Приведу только один показательный пример. В ТЗ было предусмотрено создание нового документа, который работал со складом "Товары в пути". И программисты Франчайзи просто забыли включить этот документ в последовательность ПартионныйУчёт и ПартионныйУчётБУ. Последствия для завода? Искажения в учёте уже на десятки миллионов руб. Поймал эту проблему на тестовом периоде.
Приёмка работ
Франчайзи высылает предоставляет Вам конфигурацию, Вы проверяете.
Обычно в договорах Франчайзи указывают срок проверки 5 дней (такой срок определен в Гражданском кодексе). Нужно при заключении договора предусмотреть вариант последовательной проверки каждого этапа ТЗ в отдельности. Если этап достаточно большой и включает много изменений, разбивайте его на подэтапы, которые должны приниматься отдельно. Чтобы не вышло как в моём случае, свалили все этапы вместе - проверяте за 5 дней и высылайте претензии. А между тем в предоставленной конфигурации было куча ошибок. Один небольшой кусок ТЗ Франчайзи пересдавал 4 раза! А счётчик времени то включён.
Если у Вас нет опыта работы с УПП, шансов качественно проверить работу программы нет. Поэтому, обязательно пройдите обучение по продукту. Как для УПП, так и для ИТРП есть обучающие видеокурсы. Они стоят этих денег.
Тестирование работы УПП
К сожалению, УПП нельзя сейчас назвать зрелым продуктом. Постоянно выходят исправления ошибок. Поэтому, Вам придётся проверить абсолютно все операции. Доверия к системе поначалу нет.
Моя практика. Мне пришлось проверить работу УПП на одном месяце, чтобы увидеть полную картину. Для этого была создана обработка по загрузке сведений из нашей старой системы. Часть данных бухгалтерии пришлось ввести вручную.
Как вводить остатки по запасам
Хочу только рассказать о необычной проблеме ввода остатков, с которой столкнулся впервые. В нашей старой системе учёт вёлся по ФИФО. Когда переносили остатки в УПП, то взяли сведения на начало тестируемого месяца. В результате, произошло усреднение остатков. Но формально, остатки между старой и новой системой идентичны. И здесь возникает 2 проблемы:
при сверке учёта за тестируемый период между старой системой и УПП, есть расхождения в себестоимости запасов, т.к. в старой системе выбытие запасов фиксируется по ФИФО, а в новой, хоть и указано, что по ФИФО, фактически происходит по средней (пока не спишутся все начальные остатки). В результате возникнет искажение себестоимости готовой продукции.
бухгалтерия готовит отчёт по снижению стоимости запасов с учётом сроков нахождения запасов на складах. При вводе начальных остатков, все запасы для этого отчёта будут выглядят "свеженькими". Поэтому, нужно предусмотреть в обработке занесения остатков возможность "состарить" остатки в соответствии с данными старой системы.
Моя практика. А как поживает там мой Франчайзи? "Всё хорошо". Первый перенос остатков по материалам, который пытались сдать бывшему руководителю проектов: промах всего на 3 млрд. руб. О "старении" остатков они даже не додумались. Отчёт о снижении стоимости запасов конечно же не был предусмотрен.
Запуск в эксплуатацию
Моя практика. Хоть мы и свели тестовый месяц с отклонением в себестоимости готовой продукции меньше 1%, но все-равно пришлось обезопасить себя от непредвиденных ситуаций - пришлось создать обработку по обратной выгрузке документов из УПП в старую учётную систему для сверки результатов.
Как организовать обучение сотрудников предприятия новому продукту
Обучение нужно проводить уже на готовом продукте. Т.к. будет задаваться много практических вопросов, на которые у преподавателя не всегда будет готовый ответ.
Моя практика. Могу рекомендовать не закупать стандартный курс обучения от Франчайзи - в моей практике это была бессмысленная трата денег. Гораздо эффективнее оказалась покупка видео-курса по продукту. После прохождения видео-курса, с ключевыми работниками предприятия должен плотно поработать консультант и ответить на все практические вопросы.
С чего должны начинать работать пользователи?
С ознакомления с технологическими инструкциями. За подготовку отвечает Франчайзи. Технологическую инструкцию можно представить как интерфейс между бизнес-процессом и программой.
Как закрепить результаты обучения?
Моя практика. Если у Вас приобретен видео-курс, результат останется навсегда.
Все технологические инструкции нужно внедрить в состав информационной базы (в виде справочника Инструкции). Пользователь может в любой момент к ним обратиться. И не будут возникаться вопросы от пользователей, что потерял, забыл и т.п. Также Вы сможете вносить уточнения в эти Инструкции по ходу работы.
Составить базу знаний в виде вопросов и ответов. Это уже работа на года. В моём случае нашёл путь: создание Инфа - консультанта с базой вопросов и ответов. По результатам этой работы запустил сайт 1c-expert.info - задавайте вопросы по УПП, можно будет подготовить базу по другим продуктам. Вполне может быть, что через некоторое время из Инфа выйдет хороший народный консультант.
Как защитить результаты работы от потери
Моя практика. В процессе работы над проектом у Вас будут накапливаться материалы. Я выбрал Dropbox как способ хранить файлы по проекту. Теперь я знаю, что бы ни произошло с моим ноутбуком, файлы будут сохранены. И я смогу просмотреть версии изменений этих файлов. Есть обзорная статья на Инфостарте по поводу работы этого сервиса.
Теперь уже по поводу хранения базы данных. Само собой нужны бекапы. Но нужен план архивации. И план решения проблемы в случае сбоя или в случае потери архивов. Мой план защиты данных: 2 раза в сутки делаются дифференциальные бекапы SQL-базы, 1 раз в неделю полный бекап SQL-базы. На локальном хранилище бекапы хранятся за предыдущие 30 дней и на 21 число каждого месяца за все периоды (эталон после сдачи отчетности).
Созданные архивы ежедневно копируются на наш сервер в облаке ActiveCloud (хоть вероятность одновременной потери и базы и архивов очень низка, но у меня нет желания проверить это на себе).
Информационные базы данных развёрнуты на двух серверах: основном и резервном, обмен между базами выполняется 1 раз в сутки.
Во время работы с Франчайзи, происходит постоянный обмен конфигурациями и информационными базами. Я бы порекомендовал организовать внешний ftp-сервер своими силами, где бы хранились файлы. Если возникнет судебный спор и необходима будет судебная экспертиза, суду нужно представить сохранённую копию конфигурации. Она у Вас будет. Логи сервера зафиксируют факт закачки файла.
Что делать если нет человеческих ресурсов (но есть не очень большие деньги)
Моя практика. Если Вы видите, что возникает недостаток в программистах и консультантах, то есть очень хороший вариант с фрилансерами. Поначалу я недооценивал этот ресурс. Но книга Rework: Бизнес без предрассудков и проект №2 с УПП коренным образом изменили моё мнение.
Я оказался в дико неудобной ситуации. Франчайзи, с которым был заключён договор, отказался от продолжения работы из-за недостатка ресурсов. Почти все деньги, выделенные на проект были потрачены. Завод, где я внедрял проект, находится в небольшом городе с населением 40 тыс. чел. Программистов и консультантов по 1С 8 нет. Ближайший крупный город - областной центр за 120 км. Франчайзи, с которыми я вёл переговоры, на тот момент были заняты своими проектами.
В итоге, пришлось задействовать фрилансеров. А это просто бездонный океан ресурсов! В ходе проекта я работал более с чем 20 фрилансерами, которые были разбросаны в 3 странах. Нас разделяют тысячи километров.
Конечно не со всеми были хорошие результаты, но в конце концов остались те, с которыми можно добиваться выполнения любой задачи.
Могу дать один совет: старайтесь больше ориентироваться на фрилансеров, чей основной заработок - фриланс. Если фрилансер работает как наёмный сотрудник в компании, положительные результаты будут реже. И еще 1 нюанс, программисты, чей основной заработок фриланс, в большинестве случаев (но не всегда) обладали лучшей квалификацией.
В итоге, у меня есть возможность нанять хоть 100 человек для выполнения проекта. И это за 30% от ставки Франчайзи. Неплохо, когда денег для проекта не так много.
И ещё: если рядом нет программистов и неоткуда их привлечь, то можно обучить толкового сотрудника предприятия Wink. Обычно зарплата программиста выше зарплаты рядового работника администрации и у кандидата будет интерес для перехода на новую должность.
И ещё: есть Инфостарт. За несколько лет такой поразительный рывок в качестве информации! Можно сэкономить кучу денег и времени за счёт готовых обработок и отчётов.
Ставим запуск проектов на конвейер - кейсы проектов
В книге Инструменты McKinsey. Лучшая практика решения бизнес-проблем прочитал об очень интересной идее консалтинговой компании McKinsey (создана чуть ли не век назад, специализируется на решении бизнес-проблем заказчиков, в ней работают лучшие из лучших консультантов и компания является кузницей кадров для ведущих компаний мира). Суть заключается в том, что бизнес-проблемы в работе компаний можно классифицировать. Практику решения проблем с выводами оформить в виде кейсов. В результате, когда консультанты компании приступают к работе над новым проектом, у них есть возможность изучить каким образом решались проблемы у других компаний и понять насколько этот опыт можно применить для текущего проекта. Фактически, руководство McKinsey добилась того, что накопленные знания компания не теряет с уходом консультантов.
Думаю создать сайт, на котором буду публиковать кейсы проектов 1С. Хочу предложить сообществу принять участие в формировании таких кейсов. Эта информация может помочь при работе над проектами 1С в новой для Вас области. Если у Вас есть желание и время поделиться своим опытом - будет здорово! Присылайте свои кейсы. Если получу хоть 1 кейс, обязуюсь создать сайт 1c-case.ru.
Почему я потратил время на написание этой статьи?
Это моя дань уважения Инфостарту. Проект невероятно качественный. Жаль, что его не было, когда я только начинал заниматься 1С.
P.S. Пока готовил эту статью, другой автор опубликовал статью посвященную работе над проектами 1С. Рекомендую.
P.P.S. И ещё одна интересная статья о выборе руководителя проектов.
Опубликовал Александр Тарасинский (axxell) в раздел Управление - Управление проектом
Карты памяти
Бизнес-процесс "Закупка сырья"
Управление проектом
Диаграмма состояния проекта
Таблица состояния проекта
Проектирование интерфейса
Описываю мою практику работы над проектами совместно с компаниями Франчайзи. И рекомендации по работе с такими проектами.
Предыстория:
Я работаю в достаточно большой Группе компаний, которая занимается и производством и реализацией собственной продукции. Устроился у нас руководитель проектов, которому руководство (самое высокое руководство) дало "зеленый свет" для запуска проектов. Сразу хочу сказать, что он никогда не занимался 1С, был успешный опыт запуска Axapta на нескольких заводах. Позиция нового руководителя была достаточно проста: содержать собственных программистов - дорого и не всегда эффективно, вот нанять компанию, в которой работают профессионалы и запустить быстро проект - вот это дело! И вот на волне этого позитивного заявления стартануло 2 проекта: на заводе и в торговой компании. Для внедрения привлекли не какие-то мелкие компании Франчайзи, а достаточно крупные и известные. Чем это закончилось для нас?
Кому адресована эта статья:
Кому предстоит первый раз работать с Франчайзи и у кого нет пока опыта в запуске больших проектов.
Некоторые уточнения:
Здесь я выражаю свою точку зрения. И смотрю я на эти проекты с позиции Заказчика. Позиция Франчайзи относительно результатов наверняка будет другой. Подключился к этим проектам уже на этапе запуска в эксплуатацию, когда проекты находились в достаточно плачевном состоянии. Имена Франчайзи я не буду называть. Т.к. не всегда важны имена, - а руководители проектов, как со стороны Франчайзи, так и со стороны Заказчика. Указывать компании, в которых запускались проекты тоже не имеет смысла, т.к. любая компания может повторить этот печальный опыт при стечении определенных обстоятельств.
Все гипертекстовые ссылки в этой статье ведут к открытию новых окон, чтобы не помешать чтению.
Проект 1. Внедрение системы управления складом (WMS)
Конфигурация: Управление складом
Срок подготовки проекта к запуску: 2 месяца.
Продолжительность проекта от начала до полноценной работы: 4 месяца.
Особенность проекта: WMS должна была обеспечить работу дистрибуционного и оптового склада с многоярусными стеллажами (5 и 6 уровней).
Какие главные ошибки Франчайзи: не умели работать с быстрооборачиваемыми складами и полагали, что накопленный опыт поможет запустить проект. Была предложена провальная схема работы: учитывала только обработку оптовых заказов. Также схема не соответствовала предоставленным сведениям о входящих, внутренних и исходящих товарных потоках. Не была учтена скорость работы штабелёров паллет. В итоге, предложенная Франчайзи схема работы выглядела так: каждый заказ клиента должен был обрабатываться отдельно и при отсутствии товара на нижнем ярусе необходимо было спускать паллету с верхних ярусов и поднимать обратно если на паллете оставался товар (для высвобождения места для спуска другой паллеты).
Какое решение сработало: организация области отбора товара со своевременной подпиткой с верхних ярусов.
Закончил ли Франчайзи проект: Нет, по причине несостоятельности предложить работающую схему.
Что получил Заказчик после проекта: склад запустили своими силами.
Что получил Франчайзи после проекта: узнал схему, которая была внедрена в новой версии продукта "Управление складом", переманил нашего работника (cтарший оператор WMS), который занимается проектами.
Был бы проект успешно закончен, если бы у Франчайзи было больше времени: Нет. Специально задал этот вопрос руководителю проекта со стороны Франчайзи после того как мы сами запустили проект. У Франчайзи не было такого опыта и специалисты в тот момент не были в состоянии предложить рабочую схему (сейчас уже в состоянии Wink).
Вывод: запускать проекты с Франчайзи, у которых есть опыт запуска аналогичных проектов. Если Франчайзи предлагает референс-визит на предприятие отдалённо похожее на Ваше, не соглашайтесь, ищите другого Франчайзи, у которого есть опыт с предприятими Вашего профиля. И само собой - очень хорошо нужно понимать чего хочешь и требовать выполнения этого от Франчайзи. Как самостоятельно преодолеть пропасть между пониманием и незнанием? Нанять стороннего по отношению к Франчайзи консультанта по предметной области, у которого есть успешный опыт запуска аналогичных проектов. Окупятся ли затраты на такого специалиста? Если четко поставить задачу специалисту - да.
Проект 2. Создание автоматизированной системы по управлению производством
Конфигурация: Управление производственным предприятием
Срок подготовки проекта к запуску Франчайзи: 9 месяцев (у Франчайзи времени было 3 месяца перед первым запуском и 6 месяцев перед вторым запуском).
Продолжительность проекта от начала до реального запуска: 2,5 года.
Особенности проекта. Необходим механизм планирования производства и потребностей в сырье. Движения сырья и готовой продукции должны выполняться в разрезе Серий (т.к. это пищевая промышленность и необходимо отслеживать из чего делается продукция, которую едят покупатели). Требуется постоянно отслеживать себестоимость производимой продукции.
Какие были ошибки Франчайзи: Проблема с качеством подготовки и проработки модели. Проблема с квалификацией программистов. Просчёты с оценкой трудоёмкости ввода документов. Ущербный подход к запуску проекта, когда консультанты приезжают 1 раз в неделю на 1-2 дня (мотивировали тем, что таким образом удешевляются проекты для Заказчиков, т.к. консультанты не просиживают у Заказчика. Теперь представляете какая каша из проектов может быть в голове консультантов).
Какое решение сработало: Поэтапный запуск проекта, а не все сразу: сначала запустили Зарплату, затем движения по складам, и только потом бухгалтерский и производственный учёт. Тщательная проверка абсолютно всех операций и сведение тестового месяца с сопоставленим полученных цифр в предыдущей системе. Ради справедливости стоит отметить, всё-таки удалось с Франчайзи запустить Зарплату (на это у Франчайзи еще хватило сил). И то, мне пришлось поломать схему работы Франчайзи, когда консультант приезжал на 1-2 дня на завод.
Закончил ли Франчайзи проект: Нет, по причине отсутствия кадровых ресурсов для работы над проектом и, вдобавок, прокачал на тот момент 90% бюджета.
Только ли Франчайзи виноват: Нет. Была и проблема с нашей стороны. Пытались автоматизировать неоптимальные бизнес-процессы. После оптимизации бизесс-процессов оказалось, что часть кода программистов Франчайзи можно выкинуть на свалку.
Был бы проект успешно закончен, если бы у Франчайзи было больше времени: Скорее Нет, чем да. Хоть консультанты и обладали хорошими знаниями и программистов можно было бы привлечь уровнем повыше (я не понимаю как можно внедрять коммерческие проекты и размещать в комментариях слово "говнокод" - извините, но так и было; в печатных формах документов прописывать ФИО ответственных, а не брать эти сведения из базы и т.д.). Но у Франчайзи была проблема с подходом к управлению проектами. Так можно запускать только типовые проекты, на которых руководитель проекта и команда уже набила руку.
Вывод: работать с Франчайзи, у которых есть опыт на таких же проектах по специализации и объёму. Не устраивать из проекта головокружительную гонку со сроками. Не покупаться на "космические корабли" в виде запущенного решения по планированию и оптимизации производства, планированию потребностей в сырьё. Сначала нужно организовать отражение фактических операций, а потом уже в космос.
Почему так радужно начинались и так печально закончились совместные с Франчайзи проекты
Думаю, что проблема состояла в разной точке зрения на результат проекта. Заказчик хотел в итоге получить автоматизированную систему, Франчайзи предлагал коробку с доработками. В моём случае пропасть между коробкой УПП и готовым к запуску продуктом Франчайзи не смогли закрыть.
Обобщение опыта или Чего не нужно делать на больших проектах:
Считать, что существует только единственный вариант конфигурации иноформационной базы для проекта.
Рассчитывать, что можно запустить УПП за 3 месяца (даже с учётом того, что Франчайзи обещает нагнать кучу народа). Самое интересное, что этот Франчайзи мне недавно опять предлагал помощь в запуске проекта за 3 месяца.
Побывать на класной презентации Франчайзи и думать, что у Франчайзи невероятная квалификация и все взлетит лёгким движением руки. Невероятная квалификация может быть у руководителя проекта, консультантов, программистов, задействованных на Вашем проекте. Или не на Вашем проекте Wink.
Спешить с заключением договора. Юрист предприятия должен обстоятельно проверить его. Возможно лучший вариант - привлечь стороннего юриста с большим опытом работы с такого рода договорами. Можно себя очень сильно обезопасить от неприятных последствий. Необходимость в качественно проработанном Договоре возникнет, когда проект пойдёт наперекосяк.
Рассчитывать, что некоторые операции "стандартные" и их можно запросто запустить без проверки.
Поверить в опыт Франчайзи (а не проверить).
Предполагать, что обучение преподавателями Франчайзи будет проведено на высоком уровне.
Пытаться запустить проект с помощью сотрудников Заказчика, которые параллельно с проектом выполняют и другую работу.
Предоставить Франчайзи полное право определять сколько времени будут находиться консультанты на объекте.
Полагать, что если в первый раз у Франчайзи не получится запустить проект, то во второй раз - получится.
А теперь на что нужно обратить внимание при запуске или спасении большого проекта
Организация работы руководителя проекта Заказчика
Вы должны заблаговременно освоить необходимые инструменты, которые помогут в запуске проекта. Лично я нашёл удобными для себя такие инструменты:
Карты памяти - позволяют структуировать информацию. Особенно полезны на начальном этапе, когда идёт огромный вал новых сведений. Кроме наглядного представления разрозненных поначалу данных по проекту, позволяют легче запомнить новую информацию. Я использую программный продукт MindManager. Для теоретического освоения инструмента рекомендую изучить книгу Инструменты McKinsey. Лучшая практика решения бизнес-проблем, для практического освоения - книгу Сергея Бехтерева "Майнд-менеджмент. Решение бизнес-задач с помощью интеллект-карт".
Работа над бизнес-процессами. Применяя инструменты построения бизнес-процессов, сэкономите себе и другим участникам проекта вагон времени. Я использую программный продукт BizAgi. Освоить работу с этим продуктом очень просто и здесь поможет сайт компании разработчика.
Инструмент управления проектом. Позволит разделить этапы на задачи и подзадачи с указанием сроков и ответственных. Выбрал для себя RedMine. Кроме MS Project, есть интересные онлайн сервисы Gigantt.com и Tom's planner.
Средство хранения информации по проекту. Позволит предоставить участникам проекта и заинтересованным лицам критически важную информацию. Для меня - это Google Docs.
Инструмент для проектирования интерфейсов. Позволит Вам достичь взаимопонимания с программистами. Удобным для меня стал iPlotz.
Примеры работы инструментов
1. Карты памяти позволили мне разобраться с текущим состоянием дел по проекту и упорядочить необходимые мне сведения.Карты памяти
2. Визуализация бизнес-процессов повышает качество представления информации заинтересованным лицам.Бизнес-процесс
3. RedMine как средство управления проектом позволяет не упустить ни одной мелочи.
Управление проектом
4. Google Docs - очень полезный инструмент для хранения и представления критически важной информации по проектуДиаграмма состояния проекта
Таблица состояния проекта5. Для проектирования интерфейсов есть множество инструментов. Их преимущество заключается в том, что кроме самого интерфейса, можно отобразить данные, а также можно даже создать кликабельные диалоги. Класный способ передать свои пожелания разработчику.Проектирование интерфейса
Перед началом работы с Франчайзи
Рекомендую ознакомиться с курсом ИТРП "Как избежать ошибок на проектах". Это курс даст Вам понимание работы "кухни" Франчайзи: начиная от подготовки документации по проекту и заканчивая информацией чего опасаются Франчайзи. Также Вы сможете лучше понимать мотивы руководителя проекта Франчайзи.
Какое типовое решение выбрать для автоматизации производства?
Очень интересный вопрос. Ведь все знают об УПП. Неужели нужно задуматься над этим вопросом? Оказывается нужно. И очень-очень сильно.
До начала работы над проектом, нужно хорошо понимать характер производства. От этого и нужно отталкиваться.
Есть два типа производственных предприятий: дискретные и процессные. Для каждого типа предназначена своя конфигурация. А вот теперь моё открытие: 1С предлагает для автоматизации 2 продукта. УПП рассматривается для дискретных производств. А вот когда уже функции УПП не удовлетворяют Заказчика и тип производства Заказчика - процессное, предлагается другой продукт. Тоже компании 1С - ИТРП:Процессное производство (1С купила ИТРП несколько лет назад и даже офис ИТРП напротив 1С на Селезнёвской).
В чём разница между дискретным и процессным производством? Сначала приведу примеры. Дискретное производство - машиностроение. Процессное производство - пищевая и химическая промышленость. Правило такое, если готовое изделие можно разобрать на составные части-комплектующие, это дискретное производство, нельзя - процессное производство.
Что это означало в моём случае (пищевая промышленность). Был сделан неверный выбор. Мы начали внедрять не ту конфигурацию! Но тут уже вопрос, у кого будет такая квалификация, чтобы определить поначалу что нужно внедрять? Думаю, что в ИТРП есть такие специалисты. Убедился в этом после беседы с зам. директора компании. Тем более, что ИТРП принимала участие в разработке УПП, да и разрабатывает продукты, дополняющие функциональность УПП.
Работа над проектом УПП
Цели
Любой проект начинается с целей. И Вы должны очень чётко понимать чего нужно достигнуть. Рекомендую почитать интересную статью на Инфостарте посвященную общим принципам внедрения проектов.
Цели должны быть известны до беседы с Франчайзи. В моём случае цели проекта:
Внедрить функции планирования производства и планирования закупок для обеспечения процесса безперебойного производства и сокращения запасов на складах
Обеспечить оперативный ввод в базу хозяйственных операций минута-в-минуту, добиться учёта движения сырья по всем складам на заводе в единой информационной базе с детализацией до Серий номенклатуры
Внедрить оперативный расчёт себестоимости готовой продукции, чтобы отследить рентабельность каждой отгрузки
Выбор Франчайзи для большого проекта
Объективные критерии:
Есть успешный опыт запуска аналогичных проектов. Просмотрите портфель проектов, выберите предприятие и просите организовать референс-визит.
Получите резюме специалистов, которые могут работать с Вашим проектом. Воспринимайте руководителя проекта, консультантов и программистов как специалистов, которых Вы берете на работу. Соответственно и подход должен быть такой же: без резюме и личной беседы можно сделать неверный выбор. Скайп есть у всех и не так уж трудно организовать беседу с ключевыми специалистами. Само собой это нужно делать перед заключением договора.
Оцените качество работы Франчайзи. Если у Вас есть задача, непродолжительная по времени и Вы можете передать её Франчайзи, сделайте это, чтобы проверить работу Франчайзи. Я так сходу отсеял одного Франчайзи.
Судебная практика Франчайзи, узнать причины судебных исков и какие были постановления суда.
Субъективные критерии:
Оцените как представители Франчайзи ведут диалог, как отвечают на вопросы. Смогут ли организовать беседу со специалистом по нужному профилю.
Моя практика. После того, как меня подставил Франчайзи, сообщив, что нет ресурсов для работы над проектом, я разговаривал с тремя другими Франчайзи. И самое интересное, что представители одного Франчайзи (директор и руководитель проектов) вызвали у меня профессиональную симпатию с первой беседы. Они так отвечали на вопросы и задавали их, что сходу просматривался опыт и качественная практика. К сожалению, у меня не получилось полноценно работать с этим Франчайзи, т.к. у них был слишком плотный график запуска проектов на 1 год вперёд. Но они смогли предоставить мне специалистов для работы над отдельными участками. И эта работа была выполнена на высшем уровне.
Какой Вам нужен результат после проведения тендера:
Одна компания, которая будет заниматься внедрением проекта и другая, как резерв.
Моя практика. Оказалось, что компания Франчайзи, с которой я продолжил работу над проектом УПП, участвовала в первоначальном тендере. Предшествущий руководитель проекта отсеял их, т.к. они не обещали "полететь в космос" и сообщили, что срок запуска будет больше.
Самое смешное в моей ситуации то, что стоимость проекта у резервного Франчайзи была в 2 раза ниже, чем у провального Франчайзи (резервный Франчайзи работает на местном рынке 1С). Еще смешнее ситуация, что Франчайзи, который провалил наш проект, до запуска нашего проекта собрал местных Франчайзи и предлагал им продать наш проект за 50% от стоимости Smile с аргументацией, что используют офигенную проектную технологию. Результат будет гарантирован, ну уже внедрением пусть занимается местный Франчайзи.
Поиск Франчайзи
Сайт 1С
Интернет
Знакомые
Поиск внешнего консультанта (если чувствуете недостаток знаний)
Infostart.ru - ищите публикации по Вашей тематике
Nashe1c.ru (аналог Infostart от 1С) - ищите публикации по Вашей тематике
Мой круг - множество резюме специалистов
Рекомендации по заключению и исполнению договора
Какой вид договора заключать? Договор подряда или договор оказания услуг? В книге "Как избежать ошибок на проектах" для Франчайзи рекомендуется заключение договора подряда на все этапы, кроме этапа ввода системы в эксплуатацию - здесь договор оказания услуг. В чём разница между ними? Принципиальная. Именно здесь, при работе над проектом, я и нарвался на проблему. Договор подряда заключается на результат (готовность системы к эксплуатации). А договор оказания услуг - на процесс работы. Т.е., если заключён договор оказания услуг на проект, то Франчайзи за результат никак не отвечает. Руководитель проекта работал? Работал. Программисты работали? Работали. Вот акт, что мы работали. А сможет ли продукт выполнять возложенные функции - не наша проблема.
Мои выводы:
Нужно было заключать договор подряда, а не договор оказания услуг. По договору возможна оплата по каждому этапу с подписанием акта. Но кроме актов на этапы, должен быть еще подписываться акт на результат. Полная оплата договора должна быть после подписания результирующего акта. Это означает, что акты по этапам можете подписывать на полную сумму, но оплачиваются они должны только частично согласно договоренности (например, на 80 или 90 %).
Для этапа функционального моделирования в договоре должен быть указан результат этапа - "функционирующая модель".
Если ТЗ составлял Франчайзи и будете подписывать ТЗ с такой степенью детализации, которую Вы не понимаете, то должна быть оговорка "что подписываемое ТЗ действует в рамках разумности общего пользования".
Любые действия, которые Вы должны выполнить по договору, или Франчайзи должен выполнить по договору, должны подтверждаться письменно с фиксированием ответственности. Где была моя ошибка? С руководителем проекта со стороны Франчайзи был согласован график запуска (первые два запуска прошли без меня и как понимаете - неудачно). В результате, консультант приехал к нам на завод с 1,5 месячным опозданием, а потом и вовсе руководитель проекта Франчайзи заявил, что нет свободных специалистов для работы над проектом.
В договоре должен быть указан пункт о признании юридическую силы электронной переписки.
Поддержка проекта руководством
Первостепенное значение имеет заинтересованность руководства в запуске проекта. И такая заинтересованность должна быть не формальная, а искренняя. Проверить интерес очень просто. Сколько раз у Вас спросят не только как идёт проект, но и захотят узнать детали?
Моя практика. Для меня проект по запуску УПП был открытыем. Такого интереса к проекту со стороны руководства я еще никогда в жизни не видел. Скриншоты Google Docs и BizAgi в этой статье Вы наблюдаете именно благодаря этому интересу, мне пришлось найти удобные инструменты не только для меня, но и для всех участников проекта.
Формирование рабочей группы проекта
Для работы над проектом, нужно сформировать рабочую группу на предприятии. Состав рабочей группы может со временем меняться, но некоторые сотрудники войдут в состав и будут задействованы от начала до конца проекта. Обязательно нужно договориться с руководством, чтобы сотрудники, которые войдут в состав постоянной рабочей группы, были освобождены от выполнения своих оперативных обязанностей. Им необходимо готовить замену.
Моя практика. У меня на проекте таким ключевым сотрудником является Старший экономист. Остальные сотрудники завода привлекалились в рабочую группу для работы над специфическими задачами.
Мотивация участников проекта
Вопрос премирования сотрудников за успешный запуск проекта необходимо решить с руководством до начала работы над проектом. Потому что когда в диалоге с пользователями все доводы могут быть исчерпаны, денежный вопрос может кардинальным образом повлиять на проект. Репрессии не самый лучший способ добиться лояльности по отношении к проекту. Необходимо будет согласовать для каждого сотрудника как размер премии, так и оплату за вынужденные переработки.
Моя практика. Не нужно обманывать себя, запуск проекта это не обычная рабочая нагрузка на работников. Необходимо перед началом проекта на общем собрании объявить участникам о выплате премии за успешный запуск проекта. Кроме возможности за короткий срок выполнить большой объём работы, компенсации пользователям являются инвестицией в практическое обучение по работе с новой системой.
Экспресс-обследование Франчайзи
Для проведения экспресс-обследование заключается отдельный договор. В ходе выполнения Вы присматриваетесь к работе Франчайзи, Франчайзи оценивает проект. Может сложиться такая ситуация, когда Франчайзи Вам не подойдёт, или, наоборот, Франчайзи сообщит, что откажется от проекта. Результат экспресс-обследования - указывается какие участки будут автоматизироваться, какие нужны трудозатраты и предварительная стоимостная оценка проекта. Помните, что не бывает стандартных участков. В УПП специфичныее для производств участки (да и не только для производств, но и для бухгалтерского учёта) не автоматизированы и придётся их доделывать. Если вопрос коснётся изменения внутренних механизмов работы - вот тут Вас могут ожидать проблемы и об этом лучше знать заранее.
Что выбрать РАУЗ или Партионный учёт?
Я так понимаю, что сейчас где-то в 90% компаний использует Расширенную Аналитику Учёта Затрат. Многие восторгаются этим механизмом, т.к. он избавил компании от извечных проблем связанных с вводом документов задним числом, почти избавились от блокировок транзакций. В общем, с РАУЗ жить стало проще. Для нашей компании этот механизм неприемлим. Причин есть несколько, но главная из них - подготовка отчётности по МСФО для передачи в головную компанию. РАУЗ здесь быть не может, этой методики определения стоимости выбытия запасов в МСФО нет. У нас в компании каждый год приезжают аудиторы Ernst&Young с проверкой. И в план проверки отдельным пунктом входит проверка соблюдения ФИФО (У нас в учётной политике предусмотрен этот способ). Механизм проверки очень простой, берется наугад несколько номенклатурных позиций и по ним вручную проверяется движение себестоимости по каждой операции за произвольный месяц года.
Также в РАУЗ меня смущают проблемы в расчете себестоимости при перемещении запасов со склада на склад. Об этом упоминает Игорь Бурьяненко в Продвинутом курсе по учёту производства в УПП.
Моя практика. Где у меня были проблемы с моим с Франчайзи? В модели бухучёта, которую подготовили специалисты Франчайзи, было чётко прописано, что используется Партионный учёт. А сдачу пытались провести по РАУЗ. Смешно Wink. Так и не сдали. Сначала представили как ошибку конфигурации, потом сказали, что мы данные неверно вводили, потом - просто сбежали из-за нехватки ресурсов.
Функциональное моделирование
Ключевая стадия проекта, в которой проводится анализ бизнес-процессов: как есть, как должно быть. Причём особое внимание нужно уделить разделу "как должно быть". Ведь не зря Заказчик начинает проект автоматизации, значит ситуация "как есть" не устраивает. Разработанные бизнес-процессы будут сопоставляться с возможностями типовой конфигурации. Исходя из результатов, будет сформирована оценка проекта. Здесь рабочая группа со стороны Заказчика должна пополниться специалистами, которые отвечают и знают автоматизируемые участки. В этот момент, состав рабочей группы наиполный.
Один нюанс. Для качественной проработки автоматизируемых участков в ситуации "как есть" нужно поработать с самыми компетентными специалистами по участку на предприятии. Руководитель поразделения не всегда располагает большим количеством свободного времени для такой работы. Именно в беседах со специалистами, Вы сможете выявить такие "мелочи", которые для проекта могут оказаться огромными. Для выявления "как должно быть" уже нужна работа с руководителями подразделений. Т.е. функциональное моделирование должно выполняться с участием пользователей будущей системы.
Моя практика. Т.к. я подключился к проекту уже намного позже, то могу предположить, что в состав входили: Финансовый директор, Главный бухгалтер, Главный экономист, Директора по производству и их заместители, Руководители складов, Руководитель логистики. Если говорить о качестве работы Франчайзи, то это такие "мелочи", которые возникнуть могли из-за того, что не было работы с исполнителями:
моделирование Зарплаты - "забыли" предусмотреть создание мехнизма по выгрузке сведений для банка по выплате зарплаты на зарплатные карточки. В результате, 1000 работников завода могло остаться без зарплаты. Пришлось в авральном порядке программисту Франчайзи написать обработку выгрузки. Казалось бы ничтожная по объему работа. Но последствия могли быть очень неприятные.
моделирование бухучёта в части расчета себестоимости - "забыли" предусмотреть механизм распределения общепроизводственных расходов, когда базой распределения является выпуск готовой продукции за предыдущие периоды. Тоже как будто мелочь. Но последствия - расхождения на миллионы рублей в себестоимости.
В итоге - картина маслом - моделирование выполнено формально, для галочки.
Я привёл только некоторые пункты. Чтобы всё рассказать нужно написать отдельную статью.
Что такое технический проект и техническое задание и кто за них отвечает
Техническое задание (далее ТЗ) - это функциональные требования к создаваемому продукту, Технический проект - способ реализации этих требований. Соответственно за техзадание совместная ответственность Заказчика с Франчайзи (или Заказчика, если берет на себя ответственность подготовку ТЗ), за технический проект - Франчайзи. Техзадание может составляться как специалистами Франчайзи, так и Заказчиком (в зависимости от уровня квалификации). Техпроект готовит Франчайзи. Нужно было требовать техпроект для ознакомления.
Крайне важный шаг. От него зависит качество работы системы. Не пропустите его. ТЗ Вы должны идеально понимать.
Также, в случае возникновения спора с Франчайзи и проведения экспертизы в суде - именно по этому документу эксперт и будет делать заключение о полноте выполненных работ.
Моя практика. Какие были ошибки Франчайзи? Приведу только один показательный пример. В ТЗ было предусмотрено создание нового документа, который работал со складом "Товары в пути". И программисты Франчайзи просто забыли включить этот документ в последовательность ПартионныйУчёт и ПартионныйУчётБУ. Последствия для завода? Искажения в учёте уже на десятки миллионов руб. Поймал эту проблему на тестовом периоде.
Приёмка работ
Франчайзи высылает предоставляет Вам конфигурацию, Вы проверяете.
Обычно в договорах Франчайзи указывают срок проверки 5 дней (такой срок определен в Гражданском кодексе). Нужно при заключении договора предусмотреть вариант последовательной проверки каждого этапа ТЗ в отдельности. Если этап достаточно большой и включает много изменений, разбивайте его на подэтапы, которые должны приниматься отдельно. Чтобы не вышло как в моём случае, свалили все этапы вместе - проверяте за 5 дней и высылайте претензии. А между тем в предоставленной конфигурации было куча ошибок. Один небольшой кусок ТЗ Франчайзи пересдавал 4 раза! А счётчик времени то включён.
Если у Вас нет опыта работы с УПП, шансов качественно проверить работу программы нет. Поэтому, обязательно пройдите обучение по продукту. Как для УПП, так и для ИТРП есть обучающие видеокурсы. Они стоят этих денег.
Тестирование работы УПП
К сожалению, УПП нельзя сейчас назвать зрелым продуктом. Постоянно выходят исправления ошибок. Поэтому, Вам придётся проверить абсолютно все операции. Доверия к системе поначалу нет.
Моя практика. Мне пришлось проверить работу УПП на одном месяце, чтобы увидеть полную картину. Для этого была создана обработка по загрузке сведений из нашей старой системы. Часть данных бухгалтерии пришлось ввести вручную.
Как вводить остатки по запасам
Хочу только рассказать о необычной проблеме ввода остатков, с которой столкнулся впервые. В нашей старой системе учёт вёлся по ФИФО. Когда переносили остатки в УПП, то взяли сведения на начало тестируемого месяца. В результате, произошло усреднение остатков. Но формально, остатки между старой и новой системой идентичны. И здесь возникает 2 проблемы:
при сверке учёта за тестируемый период между старой системой и УПП, есть расхождения в себестоимости запасов, т.к. в старой системе выбытие запасов фиксируется по ФИФО, а в новой, хоть и указано, что по ФИФО, фактически происходит по средней (пока не спишутся все начальные остатки). В результате возникнет искажение себестоимости готовой продукции.
бухгалтерия готовит отчёт по снижению стоимости запасов с учётом сроков нахождения запасов на складах. При вводе начальных остатков, все запасы для этого отчёта будут выглядят "свеженькими". Поэтому, нужно предусмотреть в обработке занесения остатков возможность "состарить" остатки в соответствии с данными старой системы.
Моя практика. А как поживает там мой Франчайзи? "Всё хорошо". Первый перенос остатков по материалам, который пытались сдать бывшему руководителю проектов: промах всего на 3 млрд. руб. О "старении" остатков они даже не додумались. Отчёт о снижении стоимости запасов конечно же не был предусмотрен.
Запуск в эксплуатацию
Моя практика. Хоть мы и свели тестовый месяц с отклонением в себестоимости готовой продукции меньше 1%, но все-равно пришлось обезопасить себя от непредвиденных ситуаций - пришлось создать обработку по обратной выгрузке документов из УПП в старую учётную систему для сверки результатов.
Как организовать обучение сотрудников предприятия новому продукту
Обучение нужно проводить уже на готовом продукте. Т.к. будет задаваться много практических вопросов, на которые у преподавателя не всегда будет готовый ответ.
Моя практика. Могу рекомендовать не закупать стандартный курс обучения от Франчайзи - в моей практике это была бессмысленная трата денег. Гораздо эффективнее оказалась покупка видео-курса по продукту. После прохождения видео-курса, с ключевыми работниками предприятия должен плотно поработать консультант и ответить на все практические вопросы.
С чего должны начинать работать пользователи?
С ознакомления с технологическими инструкциями. За подготовку отвечает Франчайзи. Технологическую инструкцию можно представить как интерфейс между бизнес-процессом и программой.
Как закрепить результаты обучения?
Моя практика. Если у Вас приобретен видео-курс, результат останется навсегда.
Все технологические инструкции нужно внедрить в состав информационной базы (в виде справочника Инструкции). Пользователь может в любой момент к ним обратиться. И не будут возникаться вопросы от пользователей, что потерял, забыл и т.п. Также Вы сможете вносить уточнения в эти Инструкции по ходу работы.
Составить базу знаний в виде вопросов и ответов. Это уже работа на года. В моём случае нашёл путь: создание Инфа - консультанта с базой вопросов и ответов. По результатам этой работы запустил сайт 1c-expert.info - задавайте вопросы по УПП, можно будет подготовить базу по другим продуктам. Вполне может быть, что через некоторое время из Инфа выйдет хороший народный консультант.
Как защитить результаты работы от потери
Моя практика. В процессе работы над проектом у Вас будут накапливаться материалы. Я выбрал Dropbox как способ хранить файлы по проекту. Теперь я знаю, что бы ни произошло с моим ноутбуком, файлы будут сохранены. И я смогу просмотреть версии изменений этих файлов. Есть обзорная статья на Инфостарте по поводу работы этого сервиса.
Теперь уже по поводу хранения базы данных. Само собой нужны бекапы. Но нужен план архивации. И план решения проблемы в случае сбоя или в случае потери архивов. Мой план защиты данных: 2 раза в сутки делаются дифференциальные бекапы SQL-базы, 1 раз в неделю полный бекап SQL-базы. На локальном хранилище бекапы хранятся за предыдущие 30 дней и на 21 число каждого месяца за все периоды (эталон после сдачи отчетности).
Созданные архивы ежедневно копируются на наш сервер в облаке ActiveCloud (хоть вероятность одновременной потери и базы и архивов очень низка, но у меня нет желания проверить это на себе).
Информационные базы данных развёрнуты на двух серверах: основном и резервном, обмен между базами выполняется 1 раз в сутки.
Во время работы с Франчайзи, происходит постоянный обмен конфигурациями и информационными базами. Я бы порекомендовал организовать внешний ftp-сервер своими силами, где бы хранились файлы. Если возникнет судебный спор и необходима будет судебная экспертиза, суду нужно представить сохранённую копию конфигурации. Она у Вас будет. Логи сервера зафиксируют факт закачки файла.
Что делать если нет человеческих ресурсов (но есть не очень большие деньги)
Моя практика. Если Вы видите, что возникает недостаток в программистах и консультантах, то есть очень хороший вариант с фрилансерами. Поначалу я недооценивал этот ресурс. Но книга Rework: Бизнес без предрассудков и проект №2 с УПП коренным образом изменили моё мнение.
Я оказался в дико неудобной ситуации. Франчайзи, с которым был заключён договор, отказался от продолжения работы из-за недостатка ресурсов. Почти все деньги, выделенные на проект были потрачены. Завод, где я внедрял проект, находится в небольшом городе с населением 40 тыс. чел. Программистов и консультантов по 1С 8 нет. Ближайший крупный город - областной центр за 120 км. Франчайзи, с которыми я вёл переговоры, на тот момент были заняты своими проектами.
В итоге, пришлось задействовать фрилансеров. А это просто бездонный океан ресурсов! В ходе проекта я работал более с чем 20 фрилансерами, которые были разбросаны в 3 странах. Нас разделяют тысячи километров.
Конечно не со всеми были хорошие результаты, но в конце концов остались те, с которыми можно добиваться выполнения любой задачи.
Могу дать один совет: старайтесь больше ориентироваться на фрилансеров, чей основной заработок - фриланс. Если фрилансер работает как наёмный сотрудник в компании, положительные результаты будут реже. И еще 1 нюанс, программисты, чей основной заработок фриланс, в большинестве случаев (но не всегда) обладали лучшей квалификацией.
В итоге, у меня есть возможность нанять хоть 100 человек для выполнения проекта. И это за 30% от ставки Франчайзи. Неплохо, когда денег для проекта не так много.
И ещё: если рядом нет программистов и неоткуда их привлечь, то можно обучить толкового сотрудника предприятия Wink. Обычно зарплата программиста выше зарплаты рядового работника администрации и у кандидата будет интерес для перехода на новую должность.
И ещё: есть Инфостарт. За несколько лет такой поразительный рывок в качестве информации! Можно сэкономить кучу денег и времени за счёт готовых обработок и отчётов.
Ставим запуск проектов на конвейер - кейсы проектов
В книге Инструменты McKinsey. Лучшая практика решения бизнес-проблем прочитал об очень интересной идее консалтинговой компании McKinsey (создана чуть ли не век назад, специализируется на решении бизнес-проблем заказчиков, в ней работают лучшие из лучших консультантов и компания является кузницей кадров для ведущих компаний мира). Суть заключается в том, что бизнес-проблемы в работе компаний можно классифицировать. Практику решения проблем с выводами оформить в виде кейсов. В результате, когда консультанты компании приступают к работе над новым проектом, у них есть возможность изучить каким образом решались проблемы у других компаний и понять насколько этот опыт можно применить для текущего проекта. Фактически, руководство McKinsey добилась того, что накопленные знания компания не теряет с уходом консультантов.
Думаю создать сайт, на котором буду публиковать кейсы проектов 1С. Хочу предложить сообществу принять участие в формировании таких кейсов. Эта информация может помочь при работе над проектами 1С в новой для Вас области. Если у Вас есть желание и время поделиться своим опытом - будет здорово! Присылайте свои кейсы. Если получу хоть 1 кейс, обязуюсь создать сайт 1c-case.ru.
Почему я потратил время на написание этой статьи?
Это моя дань уважения Инфостарту. Проект невероятно качественный. Жаль, что его не было, когда я только начинал заниматься 1С.
P.S. Пока готовил эту статью, другой автор опубликовал статью посвященную работе над проектами 1С. Рекомендую.
P.P.S. И ещё одна интересная статья о выборе руководителя проектов.
Tuesday, December 13, 2016
Subscribe to:
Posts (Atom)