Как не обжечься на внедрении 1С.
Статья для руководителей организаций, планирующих внедрение на своем предприятии 1С. Описаны первые шаги заказчика к Автоматизированной Системе управления Предприятием. Статья написана руководителем проектов по внедрению 1С, основана на собственном опыте внедрений. При необдуманном подходе к внедрению, этот процесс превращается в головную боль для заказчика и станок по сжиганию денег. В данной статье описал, какие ошибки допускаются внедренцами и заказчиками, и как избежать больших финансовых вложений в собственную головную боль. В основном речь идет о внедрении конфигураций на уровне УПП и КА.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Самый лучший способ не обжечься при внедрении - это ничего не внедрять!!! Особенно, когда это делает мелкий франч. Тем более, если это УПП или КА. Только бабло вылетит в трубу. Хорошим будет вариант - это набрать в штат пару хороший программеров 1С и им поставить задачу внедрить.
(3) Согласен мелким франчам лучше не доверять крупное внедрение УПП или КА. Для подобных внедрений нужен опыт. Про пару программистов не согласен. Я знаю отличных программистов которые могут написать качественный код, но не способны внедрять. Для внедрения необходим хороший руководитель проекта, задача которого не писать код, а решать методологические задачи, бухгалтер не зная всего функционала УПП не сможет справиться с этой задачей, у хорошего программиста не хватит знаний бух учета. Плюсом ко всему необходимо руководить людьми ввод остатков, тестовая отладка и т.д.,а на штатных будут давить другие сотрудники. Мне по душе когда постановщик задачи и исполнитель разные люди, так получается более качественная работа.
Моя задача, собрать информацию и переложить алгоритм планирования из головы производственника, на плечи 1С.
.....................
Описал алгоритм и отправил расчеты и формулы заказчику, его все устроило.
.....................
Мои алгоритмы можно было порвать и выкинуть...
Обязательно нужно, чтобы заказчик предоставлял письменное тех.задание! Желательно не общее, а по каждому участку автоматизации. С подписями и согласованиями затрагиваемых служб предприятия. Тогда такого не будет. А иначе тебе скажут: мы тебе говорили, а ты видимо не услышал... не понял... не придал значения.
(9) Рамзес,
Наивный. Кто конкретно на стороне заказчика сможет составить нормальное ТЗ? А если у них в штате нет нескольких системных аналитиков?
Обычно выходит, что нужно провести предпроектные работы, - осуществить сбор требований к системе, на основании собранных требований сочинить ТЗ, потом это ТЗ согласовать с Заказчиком, на базе ТЗ сделать Спецификацию, из Спецификации получить 1С-ную конфигурацию. Так вот, все до Спецификации - это предпроектные работы, без которых нормально ничего не получиться. Основная беда, что за предпроектные работы заказчики платить не любят - типа мы готовы платить за результат. А имея на руках уже готовое ТЗ, Заказчик сможет с этим ТЗ убежать к другому исполнителю, который по готовому ТЗ сконфигурирует раза в два дешевле, чем если бы ТЗ вовсе не было.
Обязательно нужно, чтобы заказчик предоставлял письменное тех.задание! Желательно не общее, а по каждому участку автоматизации. С подписями и согласованиями затрагиваемых служб предприятия. Тогда такого не будет. А иначе тебе скажут: мы тебе говорили, а ты видимо не услышал...
Наивный. Кто конкретно на стороне заказчика сможет составить нормальное ТЗ? А если у них в штате нет нескольких системных аналитиков?
Обычно выходит, что нужно провести предпроектные работы, - осуществить сбор требований к системе, на основании собранных требований сочинить ТЗ, потом это ТЗ согласовать с Заказчиком, на базе ТЗ сделать Спецификацию, из Спецификации получить 1С-ную конфигурацию. Так вот, все до Спецификации - это предпроектные работы, без которых нормально ничего не получиться. Основная беда, что за предпроектные работы заказчики платить не любят - типа мы готовы платить за результат. А имея на руках уже готовое ТЗ, Заказчик сможет с этим ТЗ убежать к другому исполнителю, который по готовому ТЗ сконфигурирует раза в два дешевле, чем если бы ТЗ вовсе не было.
(55) Petr54-ru,
Согласен с тем, что за предпроектные работы заказчик платить не желает. Поэтому необходимо хотя бы часть этих работ взвалить на плечи заказчика. Да, исполнителю приходится принимать участие в написании ТЗ. Но делать основную работу по составлению ТЗ должен представитель заказчика. И это не обязательно должен быть системный аналитик. Пусть, например, ведущий специалист отдела, задачи которого нужно автоматизировать.
И работу по автоматизации нужно начинать только имея согласованное и подписанное ТЗ.
Согласен с тем, что за предпроектные работы заказчик платить не желает. Поэтому необходимо хотя бы часть этих работ взвалить на плечи заказчика. Да, исполнителю приходится принимать участие в написании ТЗ. Но делать основную работу по составлению ТЗ должен представитель заказчика. И это не обязательно должен быть системный аналитик. Пусть, например, ведущий специалист отдела, задачи которого нужно автоматизировать.
И работу по автоматизации нужно начинать только имея согласованное и подписанное ТЗ.
(9) Рамзес,
Иногда полезно перед внедрением и разработкой ТЗ провести обследование бизнес-процессов заказчика, чтобы более грамотно выбрать конфигурацию 1С. Как бы грамотно не было расписано ТЗ Заказчика не все в нем будет до конца правильным и верным.
Иногда полезно перед внедрением и разработкой ТЗ провести обследование бизнес-процессов заказчика, чтобы более грамотно выбрать конфигурацию 1С. Как бы грамотно не было расписано ТЗ Заказчика не все в нем будет до конца правильным и верным.
Слишком много буков, а по существу можно уложится в краткий абзац, до конца не дочитал. Скучно, не интересно, ничего нового. Расскажите фишку что ли какую нибудь или интересную историю.
(10) это же статья написана не для тех "для кого все понятно", а для тех, для которых многое не понятно. По мне так вся информация была полезной. А так обычно пишут (из практики), как вы - те, кто сам в этом всем не очень хорошо "шарит". Потому что там все слова по делу и ВСЕ СЛОВА - ОЧЕНЬ ХОРОШО ПОЯСНЯЮТ СУТЬ процесса внедрения. А если вы не понимаете простого факта, что для человека очень важно понимать, хорошо понимать суть процессов - то вряд ли вы вообще хороший внедренец. Потому что понять, разобраться, помочь другим понять, разобраться в той же программе, в которой они будут работать, а так же в новых процессах, с учетом автоматизации - это наиважнейший фактор, без него не будет успешного внедрения. И если вы этого не понимаете, не чувствуете на уровне интуиции, ну....просто у вас будет плоховато идти процесс внедрения, что бы это ни было. Пусть даже внедрение нового рецепта борща:))) Короче, еще раз - для внедренца осознавать, что ЯСНОСТЬ ПО ПРОЦЕССАМ ВАЖНЫМ, по любым важным процессам, ПОНИМАНИЕ хорошее, очень хорошее - всех важных процессов,понимание как исполнителями процессов заказчика, так и работниками любыми заказчика процессов автоматизации, в том числе "как программа работает" - что вот это по сути и явлется СОПУТСТВУЮЩЕЙ, __САМОЙ__ГЛАВНОЙ__ целью процесса внедрения - это основа основ. Внедренец понимает - что именно через ЯСНОСТЬ В ГОЛОВАХ всех заинтересованных лиц идет движение вперед. И умеет эту ясность наводить, так сказать, как у себя, при обследовании и проектировании, так и у других, при согласованиях, ну вообще при внедрении. И вот у автора статьи хорошо чувствуется понимание этого факта, естественного факта, можно сказать. А у вас, простите - наоборот, исходя из ваших заявлений, а-ля "много букв". Когда эти "буквы" ПО СУЩЕСТВУ, и ПРОЯСНЯЮТ многое важное - то нет ничего лучше их, этих букв.
(11) TO1C,
да чёй-ето сегодня? учителя русского языка на сайт что ли полезли???
везде только и дело видишь посты об орфографии да грамматике.
---
апологетам и борцам за чистоту русского языка могу ответить следующее:
ЛИТЕРАТУРНЫЙ ЯЗЫК (НЕ ТОЛЬКО РУССКИЙ - ЛЮБОЙ)
С ЕГО СТРОГИМИ ПРАВИЛАМИ ГРАММАТИКИ О ОРФОГРАФИИ
ЯВЛЯЕКТСЯ ИНФОРМАЦИОННО ИЗБЫТОЧНОЙ СИСТЕМОЙ
С ТОЧКИ ЗРЕНИЯ ТЕОРИИ ПЕРЕДАЧИ ИНФОРМАЦИИ.
---
Т.е. чтобы 2 человека поняли друг-друга не требуется строго соблюдать эти правила.
Допускается шум - довольно значительные отклонения от этих правил.
да чёй-ето сегодня? учителя русского языка на сайт что ли полезли???
везде только и дело видишь посты об орфографии да грамматике.
---
апологетам и борцам за чистоту русского языка могу ответить следующее:
ЛИТЕРАТУРНЫЙ ЯЗЫК (НЕ ТОЛЬКО РУССКИЙ - ЛЮБОЙ)
С ЕГО СТРОГИМИ ПРАВИЛАМИ ГРАММАТИКИ О ОРФОГРАФИИ
ЯВЛЯЕКТСЯ ИНФОРМАЦИОННО ИЗБЫТОЧНОЙ СИСТЕМОЙ
С ТОЧКИ ЗРЕНИЯ ТЕОРИИ ПЕРЕДАЧИ ИНФОРМАЦИИ.
---
Т.е. чтобы 2 человека поняли друг-друга не требуется строго соблюдать эти правила.
Допускается шум - довольно значительные отклонения от этих правил.
(17) yuraos, потому что глаза щиплет от такого чтения)
а если серьёзно, то безграмотность может "прокатить" где-то в сообщениях на форуме, тут в комментариях, маме записку можете с ошибками написать и на холодильник повесить.. но уж если взялся статью писать - значит себя как специалиста позиционируешь, а специалист должен писать грамотно (если и не сразу, то хотя бы банально проверить орфографию после написания - труда не составляет). Написал статью с ошибками - напишешь и ТЗ с ошибками. А клиенты, особенно если это не быдлячий "босс", а какой-нибудь интеллигент-финдир, ошибки в тексте увидят сразу. Поверь, людям, которые нормально учились в школе, которые читали в своей жизни не только состав освежителя воздуха в туалете - ошибки действительно бросаются в глаза во время чтения. Попробуй потом убедить клиента, что ты не безграмотная школота и то, что написано в ТЗ - действительно будет работать.
На такую статью 1-2 ошибки было бы нормально, но не больше:).
А про избыточность русского языка пацанам во дворе расскажи.
а если серьёзно, то безграмотность может "прокатить" где-то в сообщениях на форуме, тут в комментариях, маме записку можете с ошибками написать и на холодильник повесить.. но уж если взялся статью писать - значит себя как специалиста позиционируешь, а специалист должен писать грамотно (если и не сразу, то хотя бы банально проверить орфографию после написания - труда не составляет). Написал статью с ошибками - напишешь и ТЗ с ошибками. А клиенты, особенно если это не быдлячий "босс", а какой-нибудь интеллигент-финдир, ошибки в тексте увидят сразу. Поверь, людям, которые нормально учились в школе, которые читали в своей жизни не только состав освежителя воздуха в туалете - ошибки действительно бросаются в глаза во время чтения. Попробуй потом убедить клиента, что ты не безграмотная школота и то, что написано в ТЗ - действительно будет работать.
На такую статью 1-2 ошибки было бы нормально, но не больше:).
А про избыточность русского языка пацанам во дворе расскажи.
(23) TO1C, хочется добавить:
- мы воздерживались от перехода на Бух 7.7., пока Нуралиев не заменил название справочника ДоговорА на ДоговорЫ;
- при покупке некой конфигурации мне довелось сбить цену на 10% путем указания на ошибки в названиях обработок и текстах на формах;
- может ли грамотный специалист в области информационного взаимодействия быть неграмотным в представлении информации на родном языке? Это риторический вопрос такой.
- мы воздерживались от перехода на Бух 7.7., пока Нуралиев не заменил название справочника ДоговорА на ДоговорЫ;
- при покупке некой конфигурации мне довелось сбить цену на 10% путем указания на ошибки в названиях обработок и текстах на формах;
- может ли грамотный специалист в области информационного взаимодействия быть неграмотным в представлении информации на родном языке? Это риторический вопрос такой.
(25) Арчибальд,
является ли "бизнес-аналитик" "специалистом в области информационного взаимодействия"? это вопрос такой просто
**
развернуто
может ли грамотный специалист в области информационного взаимодействия быть неграмотным в представлении информации на родном языке? Это риторический вопрос такой
является ли "бизнес-аналитик" "специалистом в области информационного взаимодействия"? это вопрос такой просто
**
развернуто
(23) если любой человек - как вы, так и заказчик способен так просто настоящий смысл поменять на некое впечатление от орфографии - ну значит он немного "путается" в жизни, не понял, что там главное. Но, надо это учитывать, согласен:))) Поэтому, ваши замечания можно принять. Но с оговоркой, что все таки СОДЕРЖАНИЕ куда важнее формы. А делать выводы о чем то ГЛАВНОМ на основании вот этих сопутствующих "кажется" - ну да, наш мир пока такой, несовершенный. Как раз в этом и есть он несовершенный. А специалист может спешить делать гораздо более важные дела, нежели проверять за собой орфографию. Я так стараюсь делать, но если нет времени - то выбираю более важное дело. Кто надо - сам разберется и расставит приоритеты. Ну а если не расставит - то значит не судьба, значит и так было нужно.
(17) yuraos, да уж не говорите, кругом всесторонние развитые люди - и в технических вещах, и в орфографии, и в стилистике. А вообще могу сказать, что те люди, которые пишут статью по сути, пишут с ошибками и опечатками. Эту статью писал автор не для филологов, а для коллег своих. И, когда автор пойдет дальше, а это явно и точно, найдет себе редактора. А сейчас и так все прекрасно!!!! Несмотря на какие-то там ошибки. И не надо писать гребаные советы! Умники что-ли? Я если честно, когда читала, в голове мысли по сути статьи, на ошибки не сильно заморачивалась, практически не заметила, потому что не в них вдумывалась.
Статья хорошая, но автору надо изучить правило написания мягкого знака после "т" в глаголах. А лучше просто зачеркнуть его везде в тексте, где он встречается. Ибо везде неправильно.
Так это же вы его написали со слов сотрудников. А должны они. Бумага их дисциплинирует, и ту ахинею, что они говорят устно, в ТЗ уже не напишут. Также при изложении в письменном виде в голове у них происходит структуризация их "хотелок". Пусть это тех.задание будет небольшого объема, но обязательно с подписью ответственного сотрудника.
А путь устного анкетирования сотрудников я уже проходил. Это выливается в бесконечное переделывание своего тех.задания.
А путь устного анкетирования сотрудников я уже проходил. Это выливается в бесконечное переделывание своего тех.задания.
(15) при достаточно сложном ТЗ тяжело заставить заказчика что то написать на бумаге обычно это сводиться к образцам отчетов и формулам. Да и если их попросить, то это затянется на пару недель. Я обычно на подобные совещания беру диктофон, во первых все что говорят в голове и на бумаге не уложишь, а во вторых немного дисциплинирует. И информацию лучше собирать одновременно с нескольких источников например начальник, мастер и бригадир. Прикольно смотреть как люди которые занимаются одним делом начинаю друг с другом спорить как делать правильно, в результате в споре рождается истина, которая мне и нужна. Потом можно написать качественное ТЗ.
Хорошее ТЗ , конечно, идеальный вариант , но заранее его получить довольносложно , сейчас занимаеемся внедрением УПП (переход с 7.7),вроде и была подготовка и нет проблем с руководством и исполнителями , но по ходу внедрения возникает масса дополнительных вопросов , задач ,заранее все предусмотреть на мой взгляд на сложном предприятии практически невозможно, но процесс все таки продвигается , хотя медленней чем хотелось бы ,динамика положительная....
(28) Короче, ВЫ МОЛОДЕЦ. ОЧЕНЬ РЕДКО увидишь, что люди СУТЬ ПРАВИЛЬНО ВЫДЕЛЯЮТ, и видно ПОНИМАНИЕ, что ГЛАВНОЕ вообще во внедрении, причем не только 1с и АСУП там и т.п.а вообще во внедрении любого чего-то нового и полезного в жизнь - я про то, что надо внести ясность вообще у всех, каким именно образом достигается то "хорошее", о чем все просят. Про то, что только постепенное внесение ясности, это вообще единственный путь, который просто бывает более или менее корявым - и от этого зависит срок. А часто бывает так, что люди НЕ ХОТЯТ прояснять ничего вообще - ну тогда процесс загибается. И много комментаторов тут этого факта не понимают, и от этого их мнения такие вот получаются. То орфография им режет глаз, то надо просто посадить внутри сотрудника:))) И давать ему каждый день бананчик еще,от него же эндорфины:))) Не слушайте их, они не шарят, в общем:)))
ЧО К ЧЕМУ. Полным полно видел таких "специлистов внутри", и годами в плане автоматизации происходит ЛАЖА. Вы бы хоть сказали, почему. Странный факт - если звучат правильные вещи, чем более они правильные,тем больше начинают там вот таких странных непонятных мнений на это выдавать. Обижаются, люди, чтобы, что сам что-то не так делают:)))
Мир этому дому! Всегда приятно знакомиться с чужим опытом работы - обязательно узнаешь для себя что-то интересное. От себя, на первое место, я бы поставил пункт: понимание целей и задач получаемых от внедрения на стороне заказчика. Если четкого понимания нет - то и проект растянется на неопределенное время, поглощая все ресурсы, которые на него будут отпущены.
Многа букав, не дочитал. На самом деле, эта статья, видимо, написана на довольно неудачном опыте. Автор даже не владеет терминологией и не имеет представления о нормальной проектной документации. Я бы посоветовал ознакомиться с PMBOK.
В общем-то, если по-нормальному, то автор хотел рассказать то, что там написано, но он постиг это на собственном опыте или эмпирическим путем.
Совсем автор позабыл про еще один фактор, который ВСЕГДА играет важную роль - "кто с кем спит", что называется. Отношения внутри коллектива Заказчика влияют на процесс внедрения непосредственно, поскольку все участники проекта должны друг с другом взаимодействовать, но по тем или иным причинам у них это не получается. Представляете, сидели менеджеры и не общались с кладовщиком за 5 лет ни разу (только на собраниях, склад находится удаленно), а тут врываетесь вы и говорите, что надо делать все по-другому. Это объясняется просто - человеческими отношениями внутри коллектива. Как правило, это кладовщик-менеджер, или женский коллектив-мужской коллектив. И тут важной найти человека, который все про всех знает и поможет Вам построить процесс внедрения настолько мягко, насколько это возможно. Как правило, это женщина (кладовщик/бухгалтер/расчетчик/технолог/.....), которая работает на предприятии довольно давно.
Случай 1:
На заводе работают 3 сына коммерческого директора - 2 менеджера и 1 мастер склада. Мало того, что они между собой общаются как абсолютно чужие люди в автобусе (типа, "передайте за проезд"), дык их еще и остальные не очень-то любят. Выход - построить работу программы так, чтобы они между собой не должны общаться больше, чем сейчас, например, сделать бизнес-процесс с документами и выводить нужную информацию на рабочем столе.
Случай 2:
На производстве работает только женский коллектив, с мужским коллективом (в основном, обслуживающий персонал и грузчики) у них крайнее неприятие. Выход: все женщины любят мужиков, на самом-то деле (не будем затрагивать тему однополых отношений). Узнайте кто у них "главарь", пригласите на чашечку чая и пообщайтесь. Человек Вам тут же раскроется, будьте уверены! А уж через него Вы повлияете и на остальной коллектив.
В общем, кроме всего прочего, надо быть немного психологом.
В общем-то, если по-нормальному, то автор хотел рассказать то, что там написано, но он постиг это на собственном опыте или эмпирическим путем.
Совсем автор позабыл про еще один фактор, который ВСЕГДА играет важную роль - "кто с кем спит", что называется. Отношения внутри коллектива Заказчика влияют на процесс внедрения непосредственно, поскольку все участники проекта должны друг с другом взаимодействовать, но по тем или иным причинам у них это не получается. Представляете, сидели менеджеры и не общались с кладовщиком за 5 лет ни разу (только на собраниях, склад находится удаленно), а тут врываетесь вы и говорите, что надо делать все по-другому. Это объясняется просто - человеческими отношениями внутри коллектива. Как правило, это кладовщик-менеджер, или женский коллектив-мужской коллектив. И тут важной найти человека, который все про всех знает и поможет Вам построить процесс внедрения настолько мягко, насколько это возможно. Как правило, это женщина (кладовщик/бухгалтер/расчетчик/технолог/.....), которая работает на предприятии довольно давно.
Случай 1:
На заводе работают 3 сына коммерческого директора - 2 менеджера и 1 мастер склада. Мало того, что они между собой общаются как абсолютно чужие люди в автобусе (типа, "передайте за проезд"), дык их еще и остальные не очень-то любят. Выход - построить работу программы так, чтобы они между собой не должны общаться больше, чем сейчас, например, сделать бизнес-процесс с документами и выводить нужную информацию на рабочем столе.
Случай 2:
На производстве работает только женский коллектив, с мужским коллективом (в основном, обслуживающий персонал и грузчики) у них крайнее неприятие. Выход: все женщины любят мужиков, на самом-то деле (не будем затрагивать тему однополых отношений). Узнайте кто у них "главарь", пригласите на чашечку чая и пообщайтесь. Человек Вам тут же раскроется, будьте уверены! А уж через него Вы повлияете и на остальной коллектив.
В общем, кроме всего прочего, надо быть немного психологом.
(34) sitec-it,
От PMBOK в 1С-ных проектах автоматизации бизнеса прока не будет, вреда кстати от этой базы знаний тоже никакого.
Если Исполнитель обладает технологиями и навыками управления проектами, и у него хватит воли провести Заказчика от этапа к этапу - от старта проекта до завершения, то цели проекта будут достигнуты. А если Исполнитель это делать не умеет, а будет озабочен лишь тем, как деньги получить, то это в первую очередь проблемы Заказчика, связанные с выбором Исполнителя.
Многа букав, не дочитал. На самом деле, эта статья, видимо, написана на довольно неудачном опыте. Автор даже не владеет терминологией и не имеет представления о нормальной проектной документации. Я бы посоветовал ознакомиться с PMBOK.
От PMBOK в 1С-ных проектах автоматизации бизнеса прока не будет, вреда кстати от этой базы знаний тоже никакого.
Если Исполнитель обладает технологиями и навыками управления проектами, и у него хватит воли провести Заказчика от этапа к этапу - от старта проекта до завершения, то цели проекта будут достигнуты. А если Исполнитель это делать не умеет, а будет озабочен лишь тем, как деньги получить, то это в первую очередь проблемы Заказчика, связанные с выбором Исполнителя.
(34)
PMBOK
Коллега, если вы ставите некую "терминологию" и знание там одной из сотен каких-то технологий описания проектов, процессов, бизнесов, систем-...уем и так далее ВЫШЕ ПОНИМАНИЯ СУТИ внедрения - то скорее у вас были не очень успешные опыты внедрения. Скорее всего менее успешные, чем у автора. Ну или вы там не были руководителем. А автор, видно,что понимает вообще весь процесс хорошо, и выделяет там главные вещи. Ну и в том числе то, что содержание важнее формы. А вот эти все "термины" - наоборот запутывают и ясности и пониманию часто мешают и затрудняют. А чаще всего, для реализации проекта, ЛЮБОГО ПРОЕКТА В ЖИЗНИ, не только внедрения - важно понимать суть, что надо ПРОСТО РАЗОБРАТЬСЯ И ПРОЯСНИТЬ все важные вопросы на пути движения к цели. А перед этим - понять хорошо эту цель и описать ее. И как там уже двигать дальше, какие там технологии и терминологии использовать - не важно. Может быть человек на ходу придумает свою технологию, которая даст фору этому всему с крутыми названиями и терминами. Которые только путают зачастую, повторюсь.
(34) а по поводу РМВОК - нафига мне тратить время на изучение кучи непонятных терминов - инициация, авторизация, еще там поди миллионы каких-нибудь "..езаций":))) - если просто суть можно ПОНЯТНЫМ ЯЗЫКОМ в гораздо проще описать. Надо просто чуть ближе постичь суть человеческих процессов любых, вот и все. И автор это просто на практике постиг и успешно делает все, без всяких там этих технологий. Где надо думать, ах мне надо же сначала этот этап сделать и потом в такую табличку все записать. Зачем? Можно просто понять СУТЬ - как и при каких условиях будет успешное движение к цели. А у таких "адептов знаний" обычно как раз нет понимания такого, в каком случае достигается цель. 100% вы ни раз не были руководителем проекта внедрения/один не внедряли сложный продукт.
(34) почитал сейчас про этот "РМВОК" - написаны правильные, ПРОСТЫЕ И ЕСТЕСТВЕННЫЕ ВЕЩИ, но сама подача такая, что запутает вообще человека и сместит приоритеты, заставив мозги работать в ненужную сторону. Почему НИГДЕ в таких местах не говорится, что ВСЕ ДОЛЖНО БЫТЬ ЦЕЛЕСООБРАЗНО???
"Управление человеческими ресурсами. Направление действий – организация проектной команды и управление ей. Планируются человеческие ресурсы, набирается и развивается коллектив, предпринимаются меры по управлению командой." - это из РМВОК - НУ ЗАЧЕМ ЭТО ВЫДЕЛЯТЬ?? Ну это же ЕЖУ ПОНЯТНО??? Надо просто сказать - подумай и прикинь, как и сколько людей тебе нужно. ПОДУМАЙ, как сделать лучше, чтобы процесс двигался вперед. ВСЕ. С учетом того, что процесс двигают люди. "Терминология"... тьфу. Вот из за таких мнений и суждений о мире нашем, которые на места естественных процессов ставят фигню всякию - вся лажа и есть у нас в жизни:)))
"Управление человеческими ресурсами. Направление действий – организация проектной команды и управление ей. Планируются человеческие ресурсы, набирается и развивается коллектив, предпринимаются меры по управлению командой." - это из РМВОК - НУ ЗАЧЕМ ЭТО ВЫДЕЛЯТЬ?? Ну это же ЕЖУ ПОНЯТНО??? Надо просто сказать - подумай и прикинь, как и сколько людей тебе нужно. ПОДУМАЙ, как сделать лучше, чтобы процесс двигался вперед. ВСЕ. С учетом того, что процесс двигают люди. "Терминология"... тьфу. Вот из за таких мнений и суждений о мире нашем, которые на места естественных процессов ставят фигню всякию - вся лажа и есть у нас в жизни:)))
Внесу свои 5 копеек. Как правило, до этого доходят все, кто занимается внедрениями проектов. Да статья написана хорошо и логично. Автор постарался доходчиво и более кратко затронуть темы внедрения проектов, хотя уже не одна статья и книга была написана на эту тему. Лично мое мнение: статья полезна тем, кто только начинает свой "тернистый" путь автоматизации, а в остальном только практика и практика. И обязательный анализ внедренных проектов, что могли бы сделать лучше, как можно было обойти возникшие проблемы и т.д. Кстати, ни разу не увидел в статье хоть одно упоминание о том, что еще необходимо ввести документацию на проекте.
(43) l_men, спасибо за комментарий.
Статья не столько написана для тех, кто начинает свой путь, сколько для людей выступающих со стороны заказчика. Некоторые заказчики считаю, что произвести автоматизацию на предприятии, это как купить автомобиль.
Анализ внедренных проектов считаю очень интересной темой, но не темой данной статьи.
С темой про документацию согласен, но заслуживает отдельной публикации. У меня есть статья, про организацию работ в начале проекта буду очень признателен за ваше мнение. На продолжение темы про документацию, к сожалению, пока нет времени.
Статья не столько написана для тех, кто начинает свой путь, сколько для людей выступающих со стороны заказчика. Некоторые заказчики считаю, что произвести автоматизацию на предприятии, это как купить автомобиль.
Анализ внедренных проектов считаю очень интересной темой, но не темой данной статьи.
С темой про документацию согласен, но заслуживает отдельной публикации. У меня есть статья, про организацию работ в начале проекта буду очень признателен за ваше мнение. На продолжение темы про документацию, к сожалению, пока нет времени.
(45) Если со стороны заказчика, то посоветую тогда заказчику внимательно читать предоставляемую документацию. Т.к. сколько было проблем, когда к ТЗ относились как к бумажке и в итоге проекты годами висели в неопределенной стадии, что то между опытной эксплуатацией и рабочей системой)) ну и со всеми вытекающими. Одна фраза, сказанная представителем заказчика стала у нас чуть ли не крылатой: "Я так и знала, что вы сделаете только то, что написано в ТЗ"))
(46) l_men, Прежде чем знакомиться с документацией которую предоставит исполнитель, этого исполнителя нужно подобрать для целей своего проекта. Не мало случаев когда недобросовестность исполнителя приводит к зависшим проектам. Что бы грамотно подойти к выбору исполнителя необходимо понимать, что из себя представляет процесс внедрения, и на что необходимо обратить внимание. Собственно эти мысли я и изложил в статье.
Основной совет для компании Заказчика, если есть такая возможность попробовать исполнителя на мелких задачах, может быть даже на каком то небольшом блоке, который можно запустить в обозримое время. Если Исполнитель показывает себя хорошо, хватку не терять, но работать можно.
А касаемо проектных технологий, в настоящий момент я вижу адекватным использовать технологию быстрого внедрения.
А касаемо проектных технологий, в настоящий момент я вижу адекватным использовать технологию быстрого внедрения.
При внедрении, особенно 6+ месяцев, Исполнителю и Заказчику надо регулярно обновлять ТЗ, т.к. на предприятии могут (и будут) меняться бизнеспроцессы.
Как в связи с уже внедренными модулями, так и с изменением законодательства, конкуренции на рынке, изменения видения бизнеса собственника. Могут быть конкурентами внедрены новые технологии, из-за чего придется полностью перестроить регламенты и производственные линии. Да много чего.
Обновление ТЗ и фиксация текущего состояния должны быть регулярными и плановыми.
Как в связи с уже внедренными модулями, так и с изменением законодательства, конкуренции на рынке, изменения видения бизнеса собственника. Могут быть конкурентами внедрены новые технологии, из-за чего придется полностью перестроить регламенты и производственные линии. Да много чего.
Обновление ТЗ и фиксация текущего состояния должны быть регулярными и плановыми.
(53) ЧИА, Согласен с обновлением.
Хотя я не пишу ТЗ на предпроектном этапе, предпочитаю составлять детальный план работ, с описанием требований. Прилагаю календарный план выполнения этих работ. В процессе внедрения как только подходим к каким-нибудь работам из плана, то непосредственно перед выполнением составляем и согласовываем ТЗ. Это позволяет еще раз взглянуть на задачу поставленную ранее и не переписывать ТЗ.
Хотя я не пишу ТЗ на предпроектном этапе, предпочитаю составлять детальный план работ, с описанием требований. Прилагаю календарный план выполнения этих работ. В процессе внедрения как только подходим к каким-нибудь работам из плана, то непосредственно перед выполнением составляем и согласовываем ТЗ. Это позволяет еще раз взглянуть на задачу поставленную ранее и не переписывать ТЗ.
На предприятии у нас (медицина) внедряется 1С в 3-х конфигурациях: БГУ, самописная "Кадры" и стандартная ЗиКБУ. Самописная конфигурация ужасная, много доработок делается. Я штатный программист, имею сертификат профессионала по ЗИКБУ. Как мне сделать, чтобы внедренцы реагировали на то, что я им пишу. Они себя позиционируют, что они опытные и внедрили такую же организацию как наша, и даже крупнее. Но по ходу общения с сотрудниками этой фирмы наткнулся на уровень профессионализма: сняли нашу конфигурацию, что-то в ней поменяли и решили залить свою, я говорю подождите я сниму копию в виде дтшника, они зачем все нормально. Снял копию с БГУ. Показал бухам, они проверили обороты. Наорали на меня, что у них ничего не сходится. Вернул обратно все. Теперь с опаской отношусь к ним. В ЗиКБУ, что ни расчет з/п то новые суммы. Начал рассчитывать январь месяц. Человек в командировке был с 10.01 по 27.01. Ему идут и командировочные, и зарплата так, что он отработал весь месяц. Лезу в начисления. В них не стоят вытесняющие начисления. Сказал, что не буду рассчитывать. Расчетчикам посоветовал, чтобы они ни в какую не подписывали никаких бумаг, потому что будут они будут виноваты. Извините за сумбур. С сентября 2014 года не могут внедрить. И еще вопросы. Есть сервер, на нем все три конфигурации крутятся. Даю пароль им админа. Они имеют полный доступ и к зарплате, и к хоздеятельности больницы. Как быть с безопасностью?
(59) paladin09,
По поводу безопасности, я бы посоветовал дать им доступ только к копии базы данных и согласовывать с вами обновление конфигурации.
Как мне сделать, чтобы внедренцы реагировали на то, что я им пишу?
Ответ простой, подписывать акты выполненных работ. Как только от вашей рецензии будет зависеть принятие их работ, Вам будет оказано особое внимание. Пускай внедренцы думают, что они умнее всех их право, но акт выполненых работ должен проходить цепочку: пользователь- ИТ специалист - Руководитель предприятия (проекта). В вашем случае кадровик-Вы-Ваш руководитель. Мотивировать необходимость данной цепочки можно тем, что рядовой пользователь не может заглянуть в код и проверить качество выполненной работы, и принимает решение о принятии работ на примере одной-двух задач.
По поводу безопасности, я бы посоветовал дать им доступ только к копии базы данных и согласовывать с вами обновление конфигурации.
Все так , действительно , подводных камней даже больше чем описано вплоть до внутриполитических взаимоотношений у заказчика, когда они на проекте друг друга выживать начинают. Мой совет прочесть книгу "Точно вовремя для России" - практика внедрения ERP систем. Но по сути описан процесс "итерационного управления проектом". Хорошо бы в продолжение темы приложить проект договора на внедрение, каким образом все эти риски - превышение бюджета, увеличения времени грамотно юридически оформить.
"Ремонт невозможно закончить - можно только прекратить!"
Михаил Жванецкий
З.Ы.
У ремонта есть начало, а конца не видать!
Ремонт равносилен пяти наводнениям.
При ремонте самым дорогим расходным материалом являются нервные клетки.
Ремонт — это стихийное бедствие, совершенное группой лиц по предварительному сговору.
Скрытые дефекты всплывают, когда нет ни денег, ни времени, чтобы их устранить.
Ремонт нужно делать, чтобы жить, а не жить, чтобы делать ремонт.
Михаил Жванецкий
З.Ы.
У ремонта есть начало, а конца не видать!
Ремонт равносилен пяти наводнениям.
При ремонте самым дорогим расходным материалом являются нервные клетки.
Ремонт — это стихийное бедствие, совершенное группой лиц по предварительному сговору.
Скрытые дефекты всплывают, когда нет ни денег, ни времени, чтобы их устранить.
Ремонт нужно делать, чтобы жить, а не жить, чтобы делать ремонт.