Осталось три дня, чтобы побороться за бесплатное участие в онлайн-курсе по управлению проектами
Продолжается голосование за самую непростую и интересную проблему в проектах!
Может быть, вам знакома история про магазин бракованных унитазов или про четырех Атабеков Атабаевичей Атабаевых, не позволивших использовать ФИО как ключевое поле? Или надоела формулировка – «Ты ж программист, сделай, чтобы все было хорошо»? А может, история о том, как во время грозы сгорел RAID со всей базой и бэкапами – про вас?
В комментариях к этой новости расскажите о самой непростой и интересной проблеме, с которой вы (или ваши коллеги) сталкивались в своих проектах? Мы просим участников Сообщества не только делиться опытом, но лайками голосовать за самую интересную историю.
Итоги конкурса поведем 1 февраля. Победитель голосования получит бесплатный доступ к онлайн-курсу «Базовый курс руководителя ИТ проекта», разработанному бизнес-тренером Марией Темчиной специально для Инфостарта. Участники курса разберут самые показательные проблемы, способы избегать и решать их.
Обучение начнется с 27 февраля.
Автор:
Дарья Расина
Редактор
Комментарии
Избранное
Подписка
Сортировка:
Древо
Моя история: идет внутренний проект внедрения, все серьезно, по Скраму. Владелец продукта собирает требования с заинтересованных лиц, их анализирует, на их основе ставит задачи разработчикам. А потом будущие ключевые пользователи бегают к команде разработки и шепотом просят: "а добавьте, пожалуйста, еще вот такую функцию, только по-тихому, чтобы Владелец продукта не узнал, а то он запрещает ее делать...". Ну и разработчики идут навстречу, куда деваться-то?..
Самый забавный проект я вел не в 1С. Тогда и 1С то еще не было.
А для одной очень серьезной организации, название которой вам не скажу, но глава ее ныне МО РФ.
Надо было записать в БД тесты группы из 10-15 человек.
Поскольку группа небольшая - ключ сделали ФИО, казалось невероятно что среди 15 человек будут такие дубли.
У первого же оттестировавшегося было четыре Атабека Атабаевича Атабаева....
Доделывали в поезде Санкт-Петербург - Москва.
Хорошо еще что "Сапсанов" тогда не было, а ноутбуки были и времени хватило
А для одной очень серьезной организации, название которой вам не скажу, но глава ее ныне МО РФ.
Надо было записать в БД тесты группы из 10-15 человек.
Поскольку группа небольшая - ключ сделали ФИО, казалось невероятно что среди 15 человек будут такие дубли.
У первого же оттестировавшегося было четыре Атабека Атабаевича Атабаева....
Доделывали в поезде Санкт-Петербург - Москва.
Хорошо еще что "Сапсанов" тогда не было, а ноутбуки были и времени хватило
Самая сложность при внедрении любого проекта, это когда заказчик у себя в голове нарисовал какую то понятную только ему ИТ-систему как она должна работать.
При внедрении сколько бы не "дергали" заказчика по всем нужным вопросам, что нужно и т.д. в итоге при окончании внедрения и перехода в ОПЭ выясняется как минимум 30-40% хотелок заказчика, а именно:
- забыл сказать
- додумал уже когда во всю шло внедрение
- подумал что в системе это уже есть
- решил что это не так важно и это не понадобиться
- найдется 1-2 сотрудника, про которых все забыли, но которые занимаются "очень важным" делом на предприятии, а ихний функционал благополучно не внедрили
- заказчик четко не может сформулировать, что ему нужно
и т.д.
А уточнить и спросить у разработчиков-внедренцев времени как всегда не хватило.
При внедрении сколько бы не "дергали" заказчика по всем нужным вопросам, что нужно и т.д. в итоге при окончании внедрения и перехода в ОПЭ выясняется как минимум 30-40% хотелок заказчика, а именно:
- забыл сказать
- додумал уже когда во всю шло внедрение
- подумал что в системе это уже есть
- решил что это не так важно и это не понадобиться
- найдется 1-2 сотрудника, про которых все забыли, но которые занимаются "очень важным" делом на предприятии, а ихний функционал благополучно не внедрили
- заказчик четко не может сформулировать, что ему нужно
и т.д.
А уточнить и спросить у разработчиков-внедренцев времени как всегда не хватило.
Serg O.; Okhovrin; VKuser2268745; feoddor; user790080; asb_andrey; Nzo; user1143095; LevRusakov; testnv0; Inziya; accounting_cons; VladimirMelnychenko; pro-rok; JohnConnor; Abazinchik; talych; alexch2002; malishevskaya_tatyana; Obuhonin; mwoleg; anton_sh; absgroup; wowik; Plotks2017; user_2010; KapasMordorov; veorts; capitan; insurgut; BEUSER; Diversus; Predator.Cat; ap@avto-pass.net;
+34
–
Ответить
(3)Больная мозоль всех внедренцев )
Обычно еще бывает так: гендир говорит - сделайте чтобы все было хорошо испдиру, испдир - финдиру, финдир - главбуху, главбух - буху, бух - программисту - ты ж программист сделай чтобы все было хорошо!
Однажды у главбуха не приняли алкогольную декларацию, она просто метнула ее вниз по цепочке без объяснений ... в результате пришлось звонить в налоговую, спрашивать что не устроило.
Они маленько офигели от таких методов постановки задач. Поржали вместе с ними конечно.
Попросили телефон гендира и кое-что ему объяснили.
Назавтра было ТЗ от главбушки и она сама вдогонку.
Обычно еще бывает так: гендир говорит - сделайте чтобы все было хорошо испдиру, испдир - финдиру, финдир - главбуху, главбух - буху, бух - программисту - ты ж программист сделай чтобы все было хорошо!
Однажды у главбуха не приняли алкогольную декларацию, она просто метнула ее вниз по цепочке без объяснений ... в результате пришлось звонить в налоговую, спрашивать что не устроило.
Они маленько офигели от таких методов постановки задач. Поржали вместе с ними конечно.
Попросили телефон гендира и кое-что ему объяснили.
Назавтра было ТЗ от главбушки и она сама вдогонку.
(3)
Вы говорите об управлении ожиданиями (управлениями требованиями Заказчика в терминах PMBoK), для этого есть роль "продавец" и "РП" кто и должны приземлять "хотелки" и неоправданные ожидания.
Мой опыт говорит, что если хочешь вообще сдать проект (не говоря об ограничениях - о треугольнике проекта) содержание и результат (продукт) проекта должен быть понятен с самого начала и однозначно трактоваться Заказчиком и Исполнителем. В случае, если состав и содержание Продукта проекта подробно разъяснено Заказчику и он это понимает, а потом говорит: "...а я думал что будет еще вот это...", это в чистом виде манипуляция и вызов, для управления такими ситуациями и существует проектная документация. В случае если продукт проекта не понятен ни Исполнителю, ни Заказчику (не могут формализовать содержание Продукта проекта), тогда Agile и вперед.
Сотрудники, про которых забыли, результат не профессионального управления, либо увеличения содержания, хотя как сказал Tom Gilb: Стейкхолдеров всегда на одного больше, чем вы знаете, а те, которых вы знаете, имеют минимум на одну потребность больше, чем вам сейчас известно.
мал уже когда во всю шло внедрение
- подумал что в системе это уже есть
- решил что это не так важно и это не понадобиться
- найдется 1-2 сотрудника, про которых все забыли, но которые занимаются "очень важным" делом на предприятии, а ихний функционал благополучно не внедрили
- заказчик четко не может сформулировать, что ему нужно
и т.д.
- подумал что в системе это уже есть
- решил что это не так важно и это не понадобиться
- найдется 1-2 сотрудника, про которых все забыли, но которые занимаются "очень важным" делом на предприятии, а ихний функционал благополучно не внедрили
- заказчик четко не может сформулировать, что ему нужно
и т.д.
Вы говорите об управлении ожиданиями (управлениями требованиями Заказчика в терминах PMBoK), для этого есть роль "продавец" и "РП" кто и должны приземлять "хотелки" и неоправданные ожидания.
Мой опыт говорит, что если хочешь вообще сдать проект (не говоря об ограничениях - о треугольнике проекта) содержание и результат (продукт) проекта должен быть понятен с самого начала и однозначно трактоваться Заказчиком и Исполнителем. В случае, если состав и содержание Продукта проекта подробно разъяснено Заказчику и он это понимает, а потом говорит: "...а я думал что будет еще вот это...", это в чистом виде манипуляция и вызов, для управления такими ситуациями и существует проектная документация. В случае если продукт проекта не понятен ни Исполнителю, ни Заказчику (не могут формализовать содержание Продукта проекта), тогда Agile и вперед.
Сотрудники, про которых забыли, результат не профессионального управления, либо увеличения содержания, хотя как сказал Tom Gilb: Стейкхолдеров всегда на одного больше, чем вы знаете, а те, которых вы знаете, имеют минимум на одну потребность больше, чем вам сейчас известно.
(47) Все красиво написали, все верно, согласен полностью. Я в частности взял плохой вариант внедрения не в Москве, а где нибудь в регионе, где я успешно работал в течении 5 лет (да и в Москве по моим данным частенько бывает что крупные интеграторы срывают все сроки). Как правило заказчик не располагает (либо не хочет платить) огромными суммами на описание и согласование устава проекта, ТЗ и тд. Да и времени у него на это зачастую нету.
Очень часто бывает что внедрение откладывается до последнего момента, а потом "очухиваются" и давай давай быстрее быстрее. А денег все хотят заработать, директор говорит нужно внедрять и начинаем внедрять. Главное заполучить заказчика и т.д. Вы говорите про идеальный правильный вариант внедрения, к нему безусловно нужно стремиться и т.д. Но в жизни, особенно в нашей стране не всегда бывает по правильному...
Очень часто бывает что внедрение откладывается до последнего момента, а потом "очухиваются" и давай давай быстрее быстрее. А денег все хотят заработать, директор говорит нужно внедрять и начинаем внедрять. Главное заполучить заказчика и т.д. Вы говорите про идеальный правильный вариант внедрения, к нему безусловно нужно стремиться и т.д. Но в жизни, особенно в нашей стране не всегда бывает по правильному...
(48)
Позвольте не согласиться:
1. Страна - это люди, которые в ней живут. Просто не берите проекты, которые высокорискованы и будут провалены по Вашему мнению. Пусть молодеж на них тренируется, а компании несут убытки.
2. Что в Мск, что в регионах Заказчик стал хитроумный. У меня раньше часто было что когда входишь в проект, видишь что Заказчик не профессионал, а спустя короткое время появляется сильный РП, который начинает выкручивать руки, если к этому не быть готовым - будет больно (особенно в регионах - нанимают РП с опытом работы в консалтинге, в KPI этого РП ставят "экономию бюджета проекта", и начинается веселье);
3. "Заказчик не готов платить за Устав, ТЗ и т.д." - аргумент простой: Вы когда машину покупаете вы за что платите? Реальная стоимость самой машины = 30% цены, за которую ее Вам продают, а что есть остальные 70%? Не хотите платить за технологий, которая приведет к нужному Вам результату, берите людей на почасовку и отвечайте за результат сами;
4. И по поводу последнего абзаца: Вы - РП, и, соответственно, несете ответственность перед: Директором, Командой, Заказчиком, Страной за результаты этого проекта. Искусство РП именно и заключается в том, чтобы окружающий хаос, превратить в результат устраивающей стейкхолдеров, либо признать и обосновать, что задача не выполнима в данных ограничениях.
Поймите, что перерасходы бюджетов, срыв сроков, недовольство не нужны никому и прежде всего Вам.
Я в частности взял плохой вариант внедрения не в Мо
Позвольте не согласиться:
1. Страна - это люди, которые в ней живут. Просто не берите проекты, которые высокорискованы и будут провалены по Вашему мнению. Пусть молодеж на них тренируется, а компании несут убытки.
2. Что в Мск, что в регионах Заказчик стал хитроумный. У меня раньше часто было что когда входишь в проект, видишь что Заказчик не профессионал, а спустя короткое время появляется сильный РП, который начинает выкручивать руки, если к этому не быть готовым - будет больно (особенно в регионах - нанимают РП с опытом работы в консалтинге, в KPI этого РП ставят "экономию бюджета проекта", и начинается веселье);
3. "Заказчик не готов платить за Устав, ТЗ и т.д." - аргумент простой: Вы когда машину покупаете вы за что платите? Реальная стоимость самой машины = 30% цены, за которую ее Вам продают, а что есть остальные 70%? Не хотите платить за технологий, которая приведет к нужному Вам результату, берите людей на почасовку и отвечайте за результат сами;
4. И по поводу последнего абзаца: Вы - РП, и, соответственно, несете ответственность перед: Директором, Командой, Заказчиком, Страной за результаты этого проекта. Искусство РП именно и заключается в том, чтобы окружающий хаос, превратить в результат устраивающей стейкхолдеров, либо признать и обосновать, что задача не выполнима в данных ограничениях.
Поймите, что перерасходы бюджетов, срыв сроков, недовольство не нужны никому и прежде всего Вам.
1. Самая непростая проблема - привить интерес к проекту людям, которые в нём не заинтересованы. Заказчик, как правило, руководитель, а работать с проектом будут подчиненные. Они боятся, что новый виток автоматизации не упростит им жизнь, а добавит работы. Так было с внедрением CRM. Исполнитель у заказчикам предпочитал известную WEB-платформу, а нам поставили задачу пересадить на 1С:УТ и обучить вести там коммерческие предложения, проекты, счета, заказы и оплаты. Перенесли данные, расширили обмен с кастомной УПП. Что в итоге? Подчиненный так и бьёт заказы в CRM, его босс его защищает, а начальник IT и ГД настаивают на решении 1С. Надеюсь текущее внедрение ERP поможет им пересесть на 1С.
Таких примеров много и все они разные.
2. Самая интересная проблема на внедрении. Такие проблемы чаще всего находятся в специфике работы компании и попытке применить их на типовом решении. Не могу выделить конкретную задачу, но в целом на опыте самое интересное - это изучение конфигурации, которую выбрал заказчик для перехода, а ты о работе с ней до этого только мечтал :)
3. Ещё одна одновременно и сложная и интересная задача на внедрении - найти консультанта и/или программиста на такой проект. И что бы не компания, а ИП или физлицо, ведь бюджет не резиновый. Переписки, согласования, ТЗ - ценнейший опыт, за который потом не стыдно ;)
Таких примеров много и все они разные.
2. Самая интересная проблема на внедрении. Такие проблемы чаще всего находятся в специфике работы компании и попытке применить их на типовом решении. Не могу выделить конкретную задачу, но в целом на опыте самое интересное - это изучение конфигурации, которую выбрал заказчик для перехода, а ты о работе с ней до этого только мечтал :)
3. Ещё одна одновременно и сложная и интересная задача на внедрении - найти консультанта и/или программиста на такой проект. И что бы не компания, а ИП или физлицо, ведь бюджет не резиновый. Переписки, согласования, ТЗ - ценнейший опыт, за который потом не стыдно ;)
Когда работал во франче, специализировался на нестандартных внедрениях. Один из клиентов помимо стандартных бухгалтерии и зарплаты использовал самописную конфигурацию на семерке для своего специфического учета. Тот, кто эту конфигурацию разработал переехал в другой город, а найти другого специалиста по поддержке клиент не смог. Наши менеджеры договорились, что если мы для них разработаем другую конфигурацию (на восьмерке), перенесем данные и внедрим, то сможем оказывать им поддержку. Задачу дали мне, мой стаж как 1Сника был примерно полтора года.
Разработал конфигурацию, перенес данные, развернул базу у клиента все показал и ушел. Получил оплату и успокоился на этом. На все ушло меньше месяца. Все были довольны.
Через полгода тот же клиент попросил "доперенести" обороты за прошедшее время: оказалось, сотрудники после моего ухода вернулись к работе в старой конфиге. Сделали за отдельную плату.
Еще где-то через год они снова обращаются к нам с той же просьбой: сотрудники все так же саботировали внедрение. Еще раз за отдельную плату внедрил все ту же конфигурацию, доработав некоторые механизмы, благо опыта набрался. Расстались на том, что сотрудники обещали работать в новой конфигурации, руководитель - следить за ними, а админ - закрыть доступ к старой базе.
Где-то через неделю я написал заявление на увольнение: перешел из франча на фикси.
Почистил свой комп от всякого хлама, включая и наработки по описанному внедрению. А еще через неделю они позвонили снова: во время грозы у них сгорел RAID с новой базой, старой базой, с их бэкапапми (привет админу) и вообще всем, что как-то было с этим связано. Зато остался шкаф с распечатками. Словом, неделька перед увольнением выдалась веселой)
Главный вывод, который я сделал: внедрение - это всегда насилие над клиентом. Уж очень часто работников клиента приходится заставлять переходить на новые системы.
Ну и еще можно сказать, что результат внедрения - это не перенос данных или разработка, т. е. не работоспособность конфигурации самой по себе, а работоспособность всей системы "БД+пользователи"
Разработал конфигурацию, перенес данные, развернул базу у клиента все показал и ушел. Получил оплату и успокоился на этом. На все ушло меньше месяца. Все были довольны.
Через полгода тот же клиент попросил "доперенести" обороты за прошедшее время: оказалось, сотрудники после моего ухода вернулись к работе в старой конфиге. Сделали за отдельную плату.
Еще где-то через год они снова обращаются к нам с той же просьбой: сотрудники все так же саботировали внедрение. Еще раз за отдельную плату внедрил все ту же конфигурацию, доработав некоторые механизмы, благо опыта набрался. Расстались на том, что сотрудники обещали работать в новой конфигурации, руководитель - следить за ними, а админ - закрыть доступ к старой базе.
Где-то через неделю я написал заявление на увольнение: перешел из франча на фикси.
Почистил свой комп от всякого хлама, включая и наработки по описанному внедрению. А еще через неделю они позвонили снова: во время грозы у них сгорел RAID с новой базой, старой базой, с их бэкапапми (привет админу) и вообще всем, что как-то было с этим связано. Зато остался шкаф с распечатками. Словом, неделька перед увольнением выдалась веселой)
Главный вывод, который я сделал: внедрение - это всегда насилие над клиентом. Уж очень часто работников клиента приходится заставлять переходить на новые системы.
Ну и еще можно сказать, что результат внедрения - это не перенос данных или разработка, т. е. не работоспособность конфигурации самой по себе, а работоспособность всей системы "БД+пользователи"
Мне кажется, самая сложная задача, когда начинается проект - это понять конфликт интересов.
Приведу пример: как только я пришел на работу в одну финансовую фирму ( это была осень 1995 года) ее руководитель поставил задачу: Управлять денежными потоками предприятия. Ну то есть, посчитать свободные деньги, посчитать кассовые разрывы, понять какие деньги предприятия и на какой срок можно вложить в финансовые активы ( облигации, векселя). Ну то есть такая работа финансового директора. И отправили меня внедрять эту методику на одно предприятие, выпускающее унитазы. Получили картбланш на эту работу от директора предприятия.
Ну и первое, что нужно было сделать - это изучить всю бухгалтерскую отчетность. Оказалось, что на предприятии картотека. А управлять картотекой дело, сами понимаете, неблагодарное. В процессе изучения отчетности выяснилось, что процент брака на предприятии огромный - почти половина. И эта бракованная продукция поступают в местный магазин, которым владеет руководство, точнее главный бухгалтер. Ну и после того, как об этом было рассказано директору, больше управлять денежными потоками нас никто не приглашал.
Сейчас схемы работы и интересы спрятаны намного серьезнее, но это совсем не значит, что их нет.
Так вот, наверное очень важно при внедрении понять, кому ты можешь наступить на горло и как, и уже затем, исходя из этого продумать стратегию внедрения.
Приведу пример: как только я пришел на работу в одну финансовую фирму ( это была осень 1995 года) ее руководитель поставил задачу: Управлять денежными потоками предприятия. Ну то есть, посчитать свободные деньги, посчитать кассовые разрывы, понять какие деньги предприятия и на какой срок можно вложить в финансовые активы ( облигации, векселя). Ну то есть такая работа финансового директора. И отправили меня внедрять эту методику на одно предприятие, выпускающее унитазы. Получили картбланш на эту работу от директора предприятия.
Ну и первое, что нужно было сделать - это изучить всю бухгалтерскую отчетность. Оказалось, что на предприятии картотека. А управлять картотекой дело, сами понимаете, неблагодарное. В процессе изучения отчетности выяснилось, что процент брака на предприятии огромный - почти половина. И эта бракованная продукция поступают в местный магазин, которым владеет руководство, точнее главный бухгалтер. Ну и после того, как об этом было рассказано директору, больше управлять денежными потоками нас никто не приглашал.
Сейчас схемы работы и интересы спрятаны намного серьезнее, но это совсем не значит, что их нет.
Так вот, наверное очень важно при внедрении понять, кому ты можешь наступить на горло и как, и уже затем, исходя из этого продумать стратегию внедрения.
(10) Даже любопытно, а что не так? Нет своих ресурсов и компетенций - значит берем подрядчика, который всем обладает, что и определяется в рамках тендера. Это в идеале конечно, но это нормальный процесс. Если вы эти сроки принимаете, значит они хоть и сжатые, но реалистичные. По крайнер мере, у вас должны быть компетенции это определить. А отказаться от проекта всегда можно.
(12)
взять подрядчика это примерно месяц- два на согласование, а сроки сжатые.
(12)
Сроки реалистичны при наличии первых двух пунктов непосредственно в компании.
(12)
Не всегда, например -если руководство говорит, что это политический проект.
значит берем подрядчика
взять подрядчика это примерно месяц- два на согласование, а сроки сжатые.
(12)
Если вы эти сроки принимаете
Сроки реалистичны при наличии первых двух пунктов непосредственно в компании.
(12)
А отказаться от проекта всегда можно.
Не всегда, например -если руководство говорит, что это политический проект.
Серьезная проблема с правильной оценкой трудозатрат. Договориться с заказчиком о реальных сроках, количестве человеко-часов.... Сначала идут на поводу у заказчика, соглашаясь на их сроки, а потом срывы сроков, в лучшем случае, доп соглашения с заказчиком, в худшем - работа в убыток....
Поработал как то в торговой сети (70 магазинов, центральная база 2 ТБ).
Самое сложное это вовремя провести накат релиза (платформа часто требует ТИИ).
Задача давно лежала на поверхности (обновление конфигурации средствами СУБД).
Решение:
1. Получаем структуру метаданных до изменения конфигурации.
2. Получаем структуру метаданных после изменения конфигурации.
3. Отключаем триггеры в таблицах с отличиями.
4. Переименовываем таблицы с данными.
5. Создаем таблицы без данных.
6. Изменяем таблицы с данными после применения изменений.
Самое сложное это вовремя провести накат релиза (платформа часто требует ТИИ).
Задача давно лежала на поверхности (обновление конфигурации средствами СУБД).
Решение:
1. Получаем структуру метаданных до изменения конфигурации.
2. Получаем структуру метаданных после изменения конфигурации.
3. Отключаем триггеры в таблицах с отличиями.
4. Переименовываем таблицы с данными.
5. Создаем таблицы без данных.
6. Изменяем таблицы с данными после применения изменений.
Самое сложно на мой взгляд это решение проблемы с тем что разработчик или другой сотрудник участвующий в процессе внедрения начинает сопереживать заказчику. Тем самым делая задачи которые нигде не указаны, в итоге не получая за это денег и со временем просто перегарая. Конкретных примеров приводить не буду, но думаю что все с этим так или иначе встречались.
Самое сложное - это сделать так, чтобы описанные, утвержденные бизнес-процессы соответствовали реальной работе. Часто автоматизируется хаос, поэтому Scrum стал популярен. Много неизвестных, нестабильности требований. Большая часть проблем проектов автоматизации лежат вне рамок автоматизации. Нужен новый тренд: комбинация консалтинговая компания (не связанных никак с 1с) + интеграторы 1с. Нужен объективный синтез, а не "разведение" на бабло.
Бизнес-образование проектной команды ниже, чем у внедняемого ПО. Молодой возраст внедренцев в реальном бизнесе и недостаток образования в сфере бизнес-администрирования это и есть основной бич проекта. Понимание цепочки заказчиков и трансляция их поведения на систему - основная задача проектной команды. Именно этого ждут заказчики и готовы в таком ключе сотрудничать.
Инициатива от собственника потому что накипело и нужен контроль.
Суть проекта - дописать и внедрить систему для детального учёта производственного процесса. Контроль и автоматические расчеты статистики.
Проблема - банальное нежелание некоторых сотрудников участвовать в процессе, потому что они понимают что в итоге у них будет больше свободного времени :) и их нагрузят чем-то ещё. И ключевая проблема - тотальное недоверие собственника к 1с.
Верхи не хотят , низы не могут или наоборот. А почему пошли по этому пути - ну все же идут, значит так надо.
Суть проекта - дописать и внедрить систему для детального учёта производственного процесса. Контроль и автоматические расчеты статистики.
Проблема - банальное нежелание некоторых сотрудников участвовать в процессе, потому что они понимают что в итоге у них будет больше свободного времени :) и их нагрузят чем-то ещё. И ключевая проблема - тотальное недоверие собственника к 1с.
Верхи не хотят , низы не могут или наоборот. А почему пошли по этому пути - ну все же идут, значит так надо.
Самая большая проблема 1С - это, то что данная программа пишется для программистов, а не для бухгалтеров. Почему до сих пор предлагается программа по частям, отдельно программа отдельно зарплата, отдельно управление. Зачастую основа предлагаемой программы настолько отличается от требований, бухгалтерского и налогового законодательства, что приходиться только удивятся, как это покупают. Поэтому общее мнение к данным программистом - рвачи и программу поэтому такую создали, чтобы только рвать. Сам занимался внедрением программ на предприятиях и в этом убедился окончательно. Пример простой внедряем программу 1 С -8,3 на предприятии, предприятие берет лизинг, а в программе данная функция даже не рассматривается, но могут доработать за отдельные деньги стоимостью в 3 программы. Хотя работы там особо не какой. Приспосабливаешь программу сам под конкретные нужды и тут выясняется, что счет 76 (специалист поймет) в котором название написано, что он валютный, мало того, что сам не переоценивается, так ещё и всю переоценку не возможно сделать, месяц закрыть невозможно, дальше по цепочке. Обращавшийся в компанию и говоришь об этом. Вместо устранения ошибки тебе пытаются "впарить спец программ" (писал выше) или сыплют заявлениями о нестандартности подхода к учету. Достаешь инструкции и документы Минфина и налоговой инспекции, где это все прописано, но даже при этих документах доработка программы оказывается стоит денег. Про перегрузку из одних блоков в другие даже не говорю. Это не проблема, а без ответственность данных компаний которые предлагают программу.
Писать могу много, намучился пока с одной из компаний дошел до баланса, и тут выяснилось, мы первые дошли до последнего штриха программы. Хотя сколько лет 1С-8?
Ответ один программа изначально создана как инструмент «кидалово" для бухгалтеров, поэтому и такие сложности при внедрении. Фактически программа "каменный век" нет полноты, простоты, удобства работы бухгалтерам. Зато огромные возможности демонстрации способностей выкачивания "денег" у заказчика. То же самое при внедрение программ управленческого учета.
Не понимание и нежелания понимать конкретных требований заказчика, неоправданно раздутые требования по оплате, и при переходе от слов к конкретным делам изображение" крутых специалистов" на самом деле такими не являющимися. Заявление о том, что данная программа пишется под конкретного заказчика вызывает смех. Хочется спросит ребят: Вы идиоты или нас держите за идиотов?». Последний раз спросил все обиделись, и свое предложение прислали через неделю, предложение на которое сказали спасибо не надо.
И если госпоже редактору интересно на данную тему можно много еще повспоминать историй про внедрение программ.
Писать могу много, намучился пока с одной из компаний дошел до баланса, и тут выяснилось, мы первые дошли до последнего штриха программы. Хотя сколько лет 1С-8?
Ответ один программа изначально создана как инструмент «кидалово" для бухгалтеров, поэтому и такие сложности при внедрении. Фактически программа "каменный век" нет полноты, простоты, удобства работы бухгалтерам. Зато огромные возможности демонстрации способностей выкачивания "денег" у заказчика. То же самое при внедрение программ управленческого учета.
Не понимание и нежелания понимать конкретных требований заказчика, неоправданно раздутые требования по оплате, и при переходе от слов к конкретным делам изображение" крутых специалистов" на самом деле такими не являющимися. Заявление о том, что данная программа пишется под конкретного заказчика вызывает смех. Хочется спросит ребят: Вы идиоты или нас держите за идиотов?». Последний раз спросил все обиделись, и свое предложение прислали через неделю, предложение на которое сказали спасибо не надо.
И если госпоже редактору интересно на данную тему можно много еще повспоминать историй про внедрение программ.
Был клиент: розница, внедряли учёт.
Только вот расположен в районе Егорьевского проезда.
Естественно поехал на электричке. Билет до ДЕПО КУР (железнодорожники называют Люблино сортировочное, а севернее Люблино дачное-для пассажира Люблино, но не метро).
Внедрение недели на 3. На 10 дней билет взял в Бутово (так как ещё 46 налоговая на Трикотажной, клиент в Калитниках, ещё случайности по мелочи) и с ним проблем не было.
А с разовыми интереснее: спрашивают что за птицы? Объяснял что никакой птицы не видел. Внедрял учёт на птицефабрике. Что? только потом выяснилось.
Билет был нужен, так как пересаживался на Каланчёвке, тогда автоматов не было и можно было потерять времени (на Курском турникетов ещё не было, поставили их очень поздно; стояли они только в горьковских тупиках).
Только вот расположен в районе Егорьевского проезда.
Естественно поехал на электричке. Билет до ДЕПО КУР (железнодорожники называют Люблино сортировочное, а севернее Люблино дачное-для пассажира Люблино, но не метро).
Внедрение недели на 3. На 10 дней билет взял в Бутово (так как ещё 46 налоговая на Трикотажной, клиент в Калитниках, ещё случайности по мелочи) и с ним проблем не было.
А с разовыми интереснее: спрашивают что за птицы? Объяснял что никакой птицы не видел. Внедрял учёт на птицефабрике. Что? только потом выяснилось.
Билет был нужен, так как пересаживался на Каланчёвке, тогда автоматов не было и можно было потерять времени (на Курском турникетов ещё не было, поставили их очень поздно; стояли они только в горьковских тупиках).
Добрый день.
Я много слышала о проблемах на проектах, о том, что в срок не укладываются, клиенты щепетильные, день ненормированный и т.п. И во всем этом я очень и очень хочу поучаствовать. Сейчас чувствую профессиональное выгорание и мечтаю попробовать реализовать свои силы на проектах, влиться в эту сферу, прочувствовать все сложности и радости от сдачи проекта. Поэтому очень хочу, чтобы мне достался такой шанс. Спасибо!
Я много слышала о проблемах на проектах, о том, что в срок не укладываются, клиенты щепетильные, день ненормированный и т.п. И во всем этом я очень и очень хочу поучаствовать. Сейчас чувствую профессиональное выгорание и мечтаю попробовать реализовать свои силы на проектах, влиться в эту сферу, прочувствовать все сложности и радости от сдачи проекта. Поэтому очень хочу, чтобы мне достался такой шанс. Спасибо!
Самые острые проблемы внедрения:
1. Отсутствие правил переноса данных, если речь об 1С-1С. Хотя казалось бы, наверняка 1000 раз уже переносили из таких конфигураций данные. Всё есть у франчей, частники набивают свои шишки, а клиенты платят за ненужные часы.
2. Заказчики. Ты написал план внедрения, расписал процесс по дням, выделив на возникающие задачи 30% времени. Как бы не так. Стоит запустить новую базу и ты 50% времени будешь тратить на консультации, остальные 50% на текущие задачи, которые появляются как головы Гидры. Сдал печатную форму? - Дайте ещё 2! А как же перенос остальных данных? К черту work&life балланс - всё свободное время в жертву новому опыту!
3. Вытекает из 2. Планирование и время. Я внедрял в командах. Сейчас внедряю в одиночку. И там и там нет такого момента, когда база будет готова на 100% к моменту запуска и после этого момента надо быть готовым на 1-2 месяца погрузиться только в проект.
Это моя точка зрения и мой опыт. Днем я программист, вечером я ИП на внедрении. Выгорел на внедрениях и сейчас думаю, что этот проект мой последний, но по опыту скажу - проекты как наркотик. Сел и на иглу и не слезешь)))
(32), Выгораешь? Смени работу. Найди работодателя с новой конфой и командой. Я менял работу раз в 1-2 года. И буду так делать пока не найду то самое место, где мне будет комфортно быть полезным и получать те знания, которые мне важны.
1. Отсутствие правил переноса данных, если речь об 1С-1С. Хотя казалось бы, наверняка 1000 раз уже переносили из таких конфигураций данные. Всё есть у франчей, частники набивают свои шишки, а клиенты платят за ненужные часы.
2. Заказчики. Ты написал план внедрения, расписал процесс по дням, выделив на возникающие задачи 30% времени. Как бы не так. Стоит запустить новую базу и ты 50% времени будешь тратить на консультации, остальные 50% на текущие задачи, которые появляются как головы Гидры. Сдал печатную форму? - Дайте ещё 2! А как же перенос остальных данных? К черту work&life балланс - всё свободное время в жертву новому опыту!
3. Вытекает из 2. Планирование и время. Я внедрял в командах. Сейчас внедряю в одиночку. И там и там нет такого момента, когда база будет готова на 100% к моменту запуска и после этого момента надо быть готовым на 1-2 месяца погрузиться только в проект.
Это моя точка зрения и мой опыт. Днем я программист, вечером я ИП на внедрении. Выгорел на внедрениях и сейчас думаю, что этот проект мой последний, но по опыту скажу - проекты как наркотик. Сел и на иглу и не слезешь)))
(32), Выгораешь? Смени работу. Найди работодателя с новой конфой и командой. Я менял работу раз в 1-2 года. И буду так делать пока не найду то самое место, где мне будет комфортно быть полезным и получать те знания, которые мне важны.
(34) На прошедшем infostart event затрагивалась тема профессионального выгорания. Кажется вывода там была примерно такие: или найди работу, которую будешь любить, или полюби свою с помощью психолога.
Переубеждать не буду, но "живём лишь раз" и "незаменимых нет". Проверено.
Переубеждать не буду, но "живём лишь раз" и "незаменимых нет". Проверено.
Как обычно всюду вмешивается политика. До 2014 г у нас в компании пользовались в качестве программы документооборота docsvision. Был он немного глючный и люди плевались иногда, но работали. Возник вопрос исправления ошибок и доработки функционала и ребята из docsvision то ли цену заломили, то ли просто поругались с нашим директором it. В итоге решено было устроить тендер на выбор новой программы документооборота. И выиграла тендер одна известная на российском рынке компания(тоже в названии есть цифра 1), которая пообещала, что выполнит все требования и за самую меньшую цену.
И начался небольшой ад. Все сроки были превышены и разработка ведется по сути до сих пор.
Периодические накаты обновлений вообще не тестировались и ошибки ложились на пользователей. Согласование документов постоянно зависало (и до сих пор так). Частенько после наката обнаруживались ошибки, которые уже были ранее исправлены.
Как итог - техподдержка ит и программисты 1с проходили курсы разработки в этой конторе и половину рабочего времени тратили не на 1с, а на уникальную программу документооборота. За пару лет отдел ит обновился на 90%. Опыт с этой программой нигде больше не пригодится.
Так вот проблема, что от той конторы никуда не уйти, потому что программу это разрабатывают только они, считай монополисты. Мы оказались в ситуации, когда ежики колются но продолжают делать дело...
Оказалось, что контора та не собиралась нас ктдать на тендере, а это у них так всегда - реальные сроки и стоимость занижена минимум в 3 раза. И ничему их жизнь не учит. Казалось бы, умножь расчет на 3. Но нет. Все новые задачи также неадекватно оценивают , а потом клянчат деньги и жалуются что сработали в минус . И так каждый раз. У самих тоже рук проектов и разработчики меняются как перчатки. Конфа на веб интерфейсе и смартах(скриптах) на уникальном языке. Сложность вхождения феерическая. Какие-то ошибки могут исправлять месяцами (отмазки, типа человек который писал хранимку уже уволился, а она сложная).
Зато наш директор it, отчитался в свое время о завершении проекта и пошел вверх по служебной лестнице
И начался небольшой ад. Все сроки были превышены и разработка ведется по сути до сих пор.
Периодические накаты обновлений вообще не тестировались и ошибки ложились на пользователей. Согласование документов постоянно зависало (и до сих пор так). Частенько после наката обнаруживались ошибки, которые уже были ранее исправлены.
Как итог - техподдержка ит и программисты 1с проходили курсы разработки в этой конторе и половину рабочего времени тратили не на 1с, а на уникальную программу документооборота. За пару лет отдел ит обновился на 90%. Опыт с этой программой нигде больше не пригодится.
Так вот проблема, что от той конторы никуда не уйти, потому что программу это разрабатывают только они, считай монополисты. Мы оказались в ситуации, когда ежики колются но продолжают делать дело...
Оказалось, что контора та не собиралась нас ктдать на тендере, а это у них так всегда - реальные сроки и стоимость занижена минимум в 3 раза. И ничему их жизнь не учит. Казалось бы, умножь расчет на 3. Но нет. Все новые задачи также неадекватно оценивают , а потом клянчат деньги и жалуются что сработали в минус . И так каждый раз. У самих тоже рук проектов и разработчики меняются как перчатки. Конфа на веб интерфейсе и смартах(скриптах) на уникальном языке. Сложность вхождения феерическая. Какие-то ошибки могут исправлять месяцами (отмазки, типа человек который писал хранимку уже уволился, а она сложная).
Зато наш директор it, отчитался в свое время о завершении проекта и пошел вверх по служебной лестнице
Одна история про саботаж.
в 2007г внедряли УПП на одном региональном заводе. До этого весь учет между отделами и бухгалтерией велся только на "бумаге". Сотрудники завода, которые не заняты непосредственно на производстве - в основном женщины в старшем возрасте, приходили на работу ровно в 8, шли на обед в 12, уходили домой по звонку ровно в 5. Зарабатывали свою среднюю по городу копеечку и, конечно, сильно не хотели, чтобы в их размеренную жизнь кто-то вносил неразбериху, пусть даже и временно. Стояла какая-то своя бухгалтерская программа, Люди делали в ворде и экселе документы, относили в бухгалтерию, тетки в бухгалтерии брали в руки сдаваемые им бумажные документы и вводили в эту программу. Собственно, руководитель проекта сразу увидел проблему и заранее договорился в руководством завода, чтобы они разослали централизовано приказ, но не в стиле, что с этого момента мы начинаем работу в 1С, а в стиле, что с такого-то числа бухгалтерия принимает документы только распечатанные из программы 1С "со штрихкодом".И сразу после этого включили штриховое кодирование документов и раздали бухгалтерии сканеры. Каково было наше удивление, когда в потоке документов часть из них сканер не определял по штрихкоду. Долго ломали голову, как такое может быть, проверяли настройки сканеров, префиксы, постфиксы и тд. А проблема оказалось банальной. Некоторые сотрудники договорились саботировать внедрение 1С и продолжали делать документы в ворде и "рисовали" руками штрихкод прямо в ворде с поморью графических инструментов. Зона комфорта - она такая заманчивая )))
в 2007г внедряли УПП на одном региональном заводе. До этого весь учет между отделами и бухгалтерией велся только на "бумаге". Сотрудники завода, которые не заняты непосредственно на производстве - в основном женщины в старшем возрасте, приходили на работу ровно в 8, шли на обед в 12, уходили домой по звонку ровно в 5. Зарабатывали свою среднюю по городу копеечку и, конечно, сильно не хотели, чтобы в их размеренную жизнь кто-то вносил неразбериху, пусть даже и временно. Стояла какая-то своя бухгалтерская программа, Люди делали в ворде и экселе документы, относили в бухгалтерию, тетки в бухгалтерии брали в руки сдаваемые им бумажные документы и вводили в эту программу. Собственно, руководитель проекта сразу увидел проблему и заранее договорился в руководством завода, чтобы они разослали централизовано приказ, но не в стиле, что с этого момента мы начинаем работу в 1С, а в стиле, что с такого-то числа бухгалтерия принимает документы только распечатанные из программы 1С "со штрихкодом".И сразу после этого включили штриховое кодирование документов и раздали бухгалтерии сканеры. Каково было наше удивление, когда в потоке документов часть из них сканер не определял по штрихкоду. Долго ломали голову, как такое может быть, проверяли настройки сканеров, префиксы, постфиксы и тд. А проблема оказалось банальной. Некоторые сотрудники договорились саботировать внедрение 1С и продолжали делать документы в ворде и "рисовали" руками штрихкод прямо в ворде с поморью графических инструментов. Зона комфорта - она такая заманчивая )))
У меня на прошлом месте работы самой большой проблемой (и причиной ухода) стал вечный проект.
Заказчиком была руководитель одного из отделов, очень скандальная дама, которая меняла "показания" (список требований) практически каждый день и плевать она хотела на ТЗ.
При каждой попытке закрыть проект и передать разработку на техподдержку отделу сопровождения отказывала, аргументируя тем, что мы не все сделали, строчила письма генеральному о срыве работы отдела.
ИТ директор ничего с ней сделать не мог и закрывал глаза, при этом в графике проектов затраты времени на этот уже не учитывались.
Заказчиком была руководитель одного из отделов, очень скандальная дама, которая меняла "показания" (список требований) практически каждый день и плевать она хотела на ТЗ.
При каждой попытке закрыть проект и передать разработку на техподдержку отделу сопровождения отказывала, аргументируя тем, что мы не все сделали, строчила письма генеральному о срыве работы отдела.
ИТ директор ничего с ней сделать не мог и закрывал глаза, при этом в графике проектов затраты времени на этот уже не учитывались.
Мой первый проект в качестве руководителя проекта.
В одной компании начался проект по внедрению 1С 8. Проект начал вести подрядчик - крупный франч.
Я пришел в компанию в качестве руководителя проекта со стороны заказчика.
На момент прихода был согласован бюджет, куплены лицензии и подписано приличное ТЗ на две сотни страниц, уже велись какие-то работы со стороны франчайзи.
Задачи были от интеграции с производственной базой 1С 7.7 до переписки драйвера ККМ и РИБ на 50 узлов.
Итерации этапов работ закрывались слабо, далеко не с первой попытки.
По итогу работы с подрядчиком пришлось самостоятельно переписывать прямые запросы к SQL базе 1С7.7, своими же силами был переписан драйвер ККМ и правила обмена РИБ.
За почти год работы с подрядчиком успеха достичь не удалось. В итоге взял себе программиста одного в офис и еще одного фрилансера на пару месяцев.
Работа сильно ускорилась. Через три месяца мы внедрили систему.
Проект завершился успешно )))
В одной компании начался проект по внедрению 1С 8. Проект начал вести подрядчик - крупный франч.
Я пришел в компанию в качестве руководителя проекта со стороны заказчика.
На момент прихода был согласован бюджет, куплены лицензии и подписано приличное ТЗ на две сотни страниц, уже велись какие-то работы со стороны франчайзи.
Задачи были от интеграции с производственной базой 1С 7.7 до переписки драйвера ККМ и РИБ на 50 узлов.
Итерации этапов работ закрывались слабо, далеко не с первой попытки.
По итогу работы с подрядчиком пришлось самостоятельно переписывать прямые запросы к SQL базе 1С7.7, своими же силами был переписан драйвер ККМ и правила обмена РИБ.
За почти год работы с подрядчиком успеха достичь не удалось. В итоге взял себе программиста одного в офис и еще одного фрилансера на пару месяцев.
Работа сильно ускорилась. Через три месяца мы внедрили систему.
Проект завершился успешно )))
Нас пригласили внедрить самописную 1С-ную конфигурацию в нескольких десятках подразделениях, но сказали: "Вы имейте ввиду, что по бумагам уже всё внедрено, акты о внедрении подписаны, высшему руководству доложено,что внедрение прошло успешно,деньги типа внедренцам заморским перечислены, так что бюджетов больших на внедрение нет, но как-то надо. Вы же красавчики, вы же нас не бросите!!!"
Во время внедрения столкнулись саботажем глав.буха, на совещани через каждое предложение звучала фраза:
" привезла раскладушку и ночую на работе..."
- Нам стало интересно, как почему законченные блоки программы буксуют в бухгалтерии и написали / сформировали отчет по пользователям:
1) Главный бухгатер - "создано 3 документа" - "время в базе 1,5 часа"
2) Зам.главного бухгалтера - "создано 400 документов" - "время в базе 270 часов в базе"
И тут руководство заинтересовалось зачем главному бухгалтеру раскладушка...
" привезла раскладушку и ночую на работе..."
- Нам стало интересно, как почему законченные блоки программы буксуют в бухгалтерии и написали / сформировали отчет по пользователям:
1) Главный бухгатер - "создано 3 документа" - "время в базе 1,5 часа"
2) Зам.главного бухгалтера - "создано 400 документов" - "время в базе 270 часов в базе"
И тут руководство заинтересовалось зачем главному бухгалтеру раскладушка...
1. внедряли в воинской части учет личного состава. И захотели перенести блок психологического тестирования из самописной конфигурации в нашу конфигурацию. Тексты тестов есть, вопросы есть, а алгоритм обработки - закрыт в коде. С начальником по воспитательной работе нашли выход: 10 вопросов по 4 варианта ответа на каждый вопрос = 1048576 вариантвов. Посадили 10 курсантов за компьютеры и за неделю перебрали все возможные варианты теста. Составили карту ответов, проанализировали и поняли алгоритм и перенесли в нашу программу. Все были довольны. В одной программе был и учет курсантов, и психологическое тестирование.
2. Поставлена задача автоматизировать проживание в вахтовых городках на газовых мегастройках нашей страны. Собрали совещание, пригласили 1С франчайзи. Стали обсуждать:
- Франчайзи поставили срок 6 месяцев на составление ТЗ и согласование доступов к личной информации ЗУПов организаций проживающих и вахтовых организаций.
- Программисты головной организации срок согласования только доступа оценили в 3 месяца. Требовали обязательное использование типовой КА (комплексной автоматизации) и справочников Сотрудники.
А надо как всегда "Вчера" - Дают 2 недели и даже премию обещали. Согласование долго...
И мы решили пойти своим путем: конфигурация с нуля, хранение на периодическом регистре сведений и регистре накопления, ключ сотрудника определялся парой полей "ФИО" - строка и ДатаРождения - Дата. Иногда можно было заполнять Паспорт и телефон, но не обязательно.
Первый день запуска был не очень удачный, т.к. использовался обычный принцип ввода информации в 1С: куча форм и табличек, заполнение полей выбором из справочников. В обычном интерфейсе нужно работать пользователям с опытом работы в 1С, а где таких на крайнем Севере найдешь?)))) Пришлось срочно переделывать (примерно как Google стала переделывать Android после презентации первого Айфона). Интерфейс минималистичный - один отчет на СКД - даже без программирования - по максимуму похожий на старую работу в XLS женщин комендантов городков. Там требуется заселить человека и выселить его.
При заселении: ищем в отчете свободную ячейку для заселения - тычим мышкой - запоняем ФИО и Дату рождения и ок. Обновляем отчет - человек живет.
Нужно выселить - ищем человека в отчете - тычим мышкой - все уже заполнено - нужно только кнопку нажать что он Выселен. Обновляем отчет - место освободилось.
В результате в ближайшие 3 месяца автоматизировали более 10 городков. А на некоторых городках обучение проводили по телефону в течении 5 минут с людьми, ни разу не видящими 1С и те начинали работать. После этого представители других организаций без долгого согласования сами захотели предоставить данные о своих сотрудниках, чтобы быстрее формировать заявки на проживание и отчеты. Поэтому успех внедрения зависит от умения анализировать предметную область.
2. Поставлена задача автоматизировать проживание в вахтовых городках на газовых мегастройках нашей страны. Собрали совещание, пригласили 1С франчайзи. Стали обсуждать:
- Франчайзи поставили срок 6 месяцев на составление ТЗ и согласование доступов к личной информации ЗУПов организаций проживающих и вахтовых организаций.
- Программисты головной организации срок согласования только доступа оценили в 3 месяца. Требовали обязательное использование типовой КА (комплексной автоматизации) и справочников Сотрудники.
А надо как всегда "Вчера" - Дают 2 недели и даже премию обещали. Согласование долго...
И мы решили пойти своим путем: конфигурация с нуля, хранение на периодическом регистре сведений и регистре накопления, ключ сотрудника определялся парой полей "ФИО" - строка и ДатаРождения - Дата. Иногда можно было заполнять Паспорт и телефон, но не обязательно.
Первый день запуска был не очень удачный, т.к. использовался обычный принцип ввода информации в 1С: куча форм и табличек, заполнение полей выбором из справочников. В обычном интерфейсе нужно работать пользователям с опытом работы в 1С, а где таких на крайнем Севере найдешь?)))) Пришлось срочно переделывать (примерно как Google стала переделывать Android после презентации первого Айфона). Интерфейс минималистичный - один отчет на СКД - даже без программирования - по максимуму похожий на старую работу в XLS женщин комендантов городков. Там требуется заселить человека и выселить его.
При заселении: ищем в отчете свободную ячейку для заселения - тычим мышкой - запоняем ФИО и Дату рождения и ок. Обновляем отчет - человек живет.
Нужно выселить - ищем человека в отчете - тычим мышкой - все уже заполнено - нужно только кнопку нажать что он Выселен. Обновляем отчет - место освободилось.
В результате в ближайшие 3 месяца автоматизировали более 10 городков. А на некоторых городках обучение проводили по телефону в течении 5 минут с людьми, ни разу не видящими 1С и те начинали работать. После этого представители других организаций без долгого согласования сами захотели предоставить данные о своих сотрудниках, чтобы быстрее формировать заявки на проживание и отчеты. Поэтому успех внедрения зависит от умения анализировать предметную область.
Внедряли мы как-то проект в одной крупной российской компании и в процессе разработки функционала запросили у бизнес-эксперта нужную нам информацию (а именно файл Excel и правило его заполнения). Эксперт отправил нас к конечному пользователю, обычному сотруднику - молодой девушке. Мы ждали от нее нужной нам информации достаточно долго: то она говорила, что еще немного нужно подождать, она скоро даст, то просто отмалчивалась.
В тоге от других "доверенных" лиц со стороны Заказчика узнали, что она каждый день истерила по поводу того, что она не будет давать нам никакую информацию, что после этого проекта ее уволят и она не будет никому нужна. Ходила по всему офису и "плакалась". Она боялась, что мы полностью автоматизируем ее ручной труд и работодатель выкинет ее улицу.
В итоге ее руководителю пришлось оказать ей психологическую помощь и объяснить, что никто ее не собирается увольнять. После чего мы быстро получили нужный файл.
P.S. После внедрения девушка продолжила работать в компании и не пострадала))
И таких историй, когда сотрудники при внедрении проектов полагают, что их уволят очень много и это часто мешает работе.
В тоге от других "доверенных" лиц со стороны Заказчика узнали, что она каждый день истерила по поводу того, что она не будет давать нам никакую информацию, что после этого проекта ее уволят и она не будет никому нужна. Ходила по всему офису и "плакалась". Она боялась, что мы полностью автоматизируем ее ручной труд и работодатель выкинет ее улицу.
В итоге ее руководителю пришлось оказать ей психологическую помощь и объяснить, что никто ее не собирается увольнять. После чего мы быстро получили нужный файл.
P.S. После внедрения девушка продолжила работать в компании и не пострадала))
И таких историй, когда сотрудники при внедрении проектов полагают, что их уволят очень много и это часто мешает работе.
Коллеги, добрый день.
Пост о пользе привлечения экспертов на проекты и о разработке кода в соответствии со стандартами фирмы «1С».
Делюсь правдивой историей из моей практики внедрения 1С:ERP. Проект, о котором пойдет речь, победил на конкурсе 1С:Проект года в 2017 году.
Итак, проект внедрения 1С:ERP по фреймворку SCRUM (Технология быстрого результата в терминах фирмы "1С"). Провели экспресс-диагностику, посмотрели серверное оборудование на предмет достаточности мощностей для 1С:ERP на 100 пользователей – фиксируем вывод что «железо потянет», но посмотрели только спецификацию оборудования специализированные тесты не проводили. На сам сервер Заказчик нас не пустил по соображениям информационной безопасности. Я понимал, что в сервере «лежит» риск. Для смягчения риска начал искать эксперта по технологическим вопросам.
Середина проекта, пользователи начинают активно работать и 1С:ERP начинает сильно тормозить, мало того, увеличено содержание проекта, теперь целевая 1С:ERP должна работать для 300 пользователей. Начинаем разбираться – «железо» на пределе возможностей, но должно тянуть. Привлекаю эксперта по технологическим вопросам, который за пару дней работы, запустив в том числе тесты Гилева, дает заключение: проблема не в «тяжеловесности» 1С:ERP, а в следующем:
1. Помимо 1С:ERP, на сервере стоит историческая система 1С:УПП сильно доработанная специалистами Заказчика и именно она «подвешивает» сервер СУБД (MS SQL) некорректными запросами, которые формируется доработанным «на коленках» кодом (не по стандартам разработки фирмы «1С»);
2. Железа будет НЕ достаточно для 300 одновременных сеансов;
Чтобы разрешить ситуацию считаю стоимость простоя предприятия из-за неработающей (висящей/тормозящей) 1С:ERP, получается 300 000 Р/час, тем самым обосновываю покупку нового сервера.
Мы не занимались поставкой оборудования и ИТ-отдел Заказчика подрядился собрать сервер по комплектующим самостоятельно. Для сравнения: фирменный сервер стоил около 2 млн. Р., бюджет сборки Сервера «на коленках» - 1,2 млн. Р.
В результате сервер собирался более 3-х месяцев, так как комплектующие заказывались по всему миру, наконец, сервер собран, но в процессе эксплуатации случились две проблемы:
1. Контроллеры не дружат с RAID-массивом (при работе с файлами размером более 4-х Гб скорость чтения/записи падает по экспоненте) – ошибка была исправлена спустя несколько месяцев, производитель контроллеров выпустил новые версии драйверов;
2. В один прекрасный день сгорели процессоры :-) – ИТ-директор, быстро купив процессоры, полетел в г. Стамбул исправлять поломку.
Для справки: стоимость простоя Предприятия из-за не работающей 1С:ERP = 300 000 Р./час, экономия на сборке сервера Noname максимум 800 000 Р.
Мораль сей были такова:
0. Работайте с рисками (диагностика, ранжирование, управление) – дешевле будет;
1. Не экономьте на технической экспертизе – много нервов и средств сбережете;
2. Не экономьте на контроле качества работ, выпуская продукт, соответствующий стандартам качества фирмы «1С» - представьте каковы последствия того, что Заказчик скажет: "...Ваша система не годна к использованию..." по завершении проекта;
3. Не экономьте на оборудовании – сейчас стоимость «железа» невысока.
Удачи на проектах!
Оводков Василий
Член Московского отделения PMI в России
Член International Project Management Association
Сертифицированный специалист по управлению проектами IPMA Level D
Сертифицированный 1С:Руководитель корпоративных проектов
Пост о пользе привлечения экспертов на проекты и о разработке кода в соответствии со стандартами фирмы «1С».
Делюсь правдивой историей из моей практики внедрения 1С:ERP. Проект, о котором пойдет речь, победил на конкурсе 1С:Проект года в 2017 году.
Итак, проект внедрения 1С:ERP по фреймворку SCRUM (Технология быстрого результата в терминах фирмы "1С"). Провели экспресс-диагностику, посмотрели серверное оборудование на предмет достаточности мощностей для 1С:ERP на 100 пользователей – фиксируем вывод что «железо потянет», но посмотрели только спецификацию оборудования специализированные тесты не проводили. На сам сервер Заказчик нас не пустил по соображениям информационной безопасности. Я понимал, что в сервере «лежит» риск. Для смягчения риска начал искать эксперта по технологическим вопросам.
Середина проекта, пользователи начинают активно работать и 1С:ERP начинает сильно тормозить, мало того, увеличено содержание проекта, теперь целевая 1С:ERP должна работать для 300 пользователей. Начинаем разбираться – «железо» на пределе возможностей, но должно тянуть. Привлекаю эксперта по технологическим вопросам, который за пару дней работы, запустив в том числе тесты Гилева, дает заключение: проблема не в «тяжеловесности» 1С:ERP, а в следующем:
1. Помимо 1С:ERP, на сервере стоит историческая система 1С:УПП сильно доработанная специалистами Заказчика и именно она «подвешивает» сервер СУБД (MS SQL) некорректными запросами, которые формируется доработанным «на коленках» кодом (не по стандартам разработки фирмы «1С»);
2. Железа будет НЕ достаточно для 300 одновременных сеансов;
Чтобы разрешить ситуацию считаю стоимость простоя предприятия из-за неработающей (висящей/тормозящей) 1С:ERP, получается 300 000 Р/час, тем самым обосновываю покупку нового сервера.
Мы не занимались поставкой оборудования и ИТ-отдел Заказчика подрядился собрать сервер по комплектующим самостоятельно. Для сравнения: фирменный сервер стоил около 2 млн. Р., бюджет сборки Сервера «на коленках» - 1,2 млн. Р.
В результате сервер собирался более 3-х месяцев, так как комплектующие заказывались по всему миру, наконец, сервер собран, но в процессе эксплуатации случились две проблемы:
1. Контроллеры не дружат с RAID-массивом (при работе с файлами размером более 4-х Гб скорость чтения/записи падает по экспоненте) – ошибка была исправлена спустя несколько месяцев, производитель контроллеров выпустил новые версии драйверов;
2. В один прекрасный день сгорели процессоры :-) – ИТ-директор, быстро купив процессоры, полетел в г. Стамбул исправлять поломку.
Для справки: стоимость простоя Предприятия из-за не работающей 1С:ERP = 300 000 Р./час, экономия на сборке сервера Noname максимум 800 000 Р.
Мораль сей были такова:
0. Работайте с рисками (диагностика, ранжирование, управление) – дешевле будет;
1. Не экономьте на технической экспертизе – много нервов и средств сбережете;
2. Не экономьте на контроле качества работ, выпуская продукт, соответствующий стандартам качества фирмы «1С» - представьте каковы последствия того, что Заказчик скажет: "...Ваша система не годна к использованию..." по завершении проекта;
3. Не экономьте на оборудовании – сейчас стоимость «железа» невысока.
Удачи на проектах!
Оводков Василий
Член Московского отделения PMI в России
Член International Project Management Association
Сертифицированный специалист по управлению проектами IPMA Level D
Сертифицированный 1С:Руководитель корпоративных проектов
Софт-Релиз; katbob; Leon29; FB_2106921756012739; FB_1285108221642879; FB_2442167175825008; FB_2120582934655335; FB_3025444384147938; user1143442; user1143348; user1143340; user1143336; paleo; user1143012; yuconst; Rokfeller; mechanikus; FB_2423136771094979; user1142963; user915379; user1142961; user737097;
+22
–
Ответить