4 ключевые проблемы проектов внедрения 1С Предприятие

05.07.13

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

Итак. Проект завален. В чем причина?

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

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

Разбираем…

Для внедрения нужны 3 ключевые роли (моя версия):

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

Для внедрения нужны 3 ключевые роли (версия В. Тарасова, (с) Управление по Макиавелли):

Фанат – тот кто знает как выглядит конечный результат, и не боится вступать в конфликт, защищая идею, если кто-то решил, вводит противоречия в проект, пытается все вернуть на прежние места;
Менеджер – тот, кто сумеет совместить старые порядки, с новыми, напишет инструкции;
Крестный отец – тот, чья сила обеспечивает движение проекта, тот кто может применять административный ресурс.

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

Кроме людей понадобится компьютер, сама программа и листок бумаги.

Если убрать в сторонку толстые книги по PMI, PM BOK, Agile … Ключевые правила, нарушение которых приводит к провалу проекта. Правила очень простые. Но нарушаются в 99% случаев.

Правило №1. Еженедельные совещание во главе с руководителем проекта (РП). Руководитель проекта задает вопросы, дает задания, с одной лишь целью… выполнить правило №2.
Правило №2. По итогам каждого совещания нужно делать отчет о состоянии проекта, который потом рассылается всей группе. Отчет очень простой, да супер эффективный, состоит из 3х разделов. Результаты по итогам прошедшего период, План действий на ближайший период, Обнаруженные проблемы. Напротив каждого важного пункта, сроки и ответственные. Можно добавлять разделы еще, но это ключевые и обязательные. Они обновляются по итогам каждого совещания.
Правило №3. Пользователям нужны инструкции. Но инструкции по процессам и функциям, а не объектам и документам программы, кои идут в комплекте. Отличие существенное и их рассмотрим ниже.
Правило №4. Служба технической поддержки, способная решать сложные технические проблемы и находить решение ошибок. Может быть удаленная. Но надежная. Потому, если нет поблизости, можно купить кого-нибудь через Интернет.

А вот теперь подробней по каждому пункту.

По правилу №1. РП это ключевая фигура. Можно нарушить любые правила и испортить все что угодно, но если РП достойный то он вырулит. Но если РП нет или вместо него Чучело, тогда на каждом совещании будем узнавать о том, что у нас снова что-то не так и сроки будут звучать «ну вот еще пару недель и все будет» или «да мы почти закончили, нужно только начать да кончить», или «не знаю сроков, тут много всяких нюансов», а может быть РП обвинит всех во всем, скажет, что все дураки, что в провале проекта виноват тот, тот или тот, а он сделал все что мог.
По правилу №2. Отчет это ключ от двери, где деньги лежат. В разделе Результаты пишем что было сделано за прошлую неделю, и все те результаты которые достигнуты по ходу проекта. В разделе План пишем те действия, которые планируются, ответственные, сроки, на следующий период. В Проблемах пишем какие-то затруднения, которые приводят к пробуксовке, и ответственных. Это может быть сам РП, программист, пользователь, или служба технической поддержки. Отчет обновляется по итогам совещания. Рассылается проектной группе. И так до следующего совещания. На следующем садимся, проходимся по пунктам, срокам, ответственным. Если срок нарушен, то нужно сделать все возможное, чтобы человеку больше не захотелось нарушать данное им слово. В общем добиваемся того чтобы в следующий раз ставили или более реальные сроки или кровь из носу выполняли те что установили.
По правилу №3. Программа это вторично. Запустить систему можно и без программы. А вот организовать процесс без инструкций это сынок фантастика. Инструкции это основа системы. Но инструкции не те что идут в комплекте с 1С Предприятие. С теми инструкциями можно идти костер разжигать. Пользователям от них толку мало, т.к. эти инструкции написаны программистами для программистов. Книги тоже дают мало пользы, особенно новичкам. Инструкция должна быть написана с точки зрения процессов и процедур. Полный порядок действий, от А до Я с картинками. Плюс условия, при которых процесс начинает ветвиться и вилять, все возможные петли. Мол если это тогда вот туда. Такие процессы идут с развитыми продуктами типа SAP, Navision, DIRECTUM, там где культура внедрения развита и есть соответствующая категория специалистов. А вот в 1С этой категории нет и соответственно знаний этих тоже. Есть программисты, которые не в курсе что такое инструкции для пользователей, что такое процессы, что такое ТЗ на внедрение. Они их путают с инструкциями по программе, а также с ТЗ на разработку, думая что это одно и тоже или что то похожее.
По правилу №4. 90% организаций продающих или внедряющих 1С до сих пор относятся к тех.поддержке как к чему-то мало важному. Обращения пользователей остаются без регистрации, теряются, забываются, забиваются. Контроля сроков нет. Доверие пользователей теряем в первые же секунды сотрудничества.

Резюме

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

(с) Группа "Технология внедрения 1С Предприятие"

+251 –4

См. также

Вооружаем торговых агентов КПК. Личный опыт.

Оптовая торговля Бизнес-анализ Платформа 1С v7.7 Платформа 1С v8.3 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

История собственного внедрения

21.06.2010 33293 0 Noy 25

Почему я не использую типовые конфигурации фирмы 1С?

Бизнес-анализ Бухгалтерский учет 7.7 1С:Торговля и склад 7.7 Россия Бухгалтерский учет Бесплатно (free)

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

28.03.2010 12498 0 Yurisel 95

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. CheBurator 2712 11.06.10 17:32 Сейчас в теме

все правильно. кроме одного, не указанного в п.2
в случае невыполнения предыдущего плана - разумнее остановить проект и добиться выполнения несделанного. Как правило - у руководителя проекта - нет прямых методов давления на сотрудников, работающих со стороны заказчика. Поэтому, если РП заинтересован именно во внедрении и запуске проекта - то остановка проекта до выполнени яназначенного - самый действенный способ. иначе в конце вроде и проект "выполнен", вроде и "работает"... но... пользы нет.. потому что выполнен хреново и работает абы как - только в присутствии "сопровожденцев"... Поэтому: если в проекте на начальном этапе не прописаны ВПОЛНЕ ЯСНЫЕ А НЕ РАСПЛЫВЧАТЫЕ ФОРМУЛИРОВКИ ПО ОТВЕТСВЕННОСТИ - тогда шанс есть, иначе - шанс резко уменьшается. Так что главное в проекте - люди. И ИНСТРУКЦИИ. надысь вот, писал инструкцию по отражению 1 одного самого простого шага из трех по "ведению" учета по импортным поставкам - 15 листов. Реально действия по инструкции занимают 15 минут. И хотя описано почти ВСЕ - пофиг!!! НЕ ЧИТАЮТ!!!!!

3. 11.06.10 18:05 Сейчас в теме

(1) я не понимаю как можно остановить проект. в среднем проекте задействовано порядка 3-5 сотрудников. каждому розданы задачи. один не справилася. машем палочкой и требуем чтобы все остановились!? это не реально.
проект не остановится, просто если речь идет о жестких сроках, какие бывают при выполнении гос.контрактов, то тут у нас появляется шанс сдвинуть срок вперед, при условии что ТЗ было составлено грамотно, и зоны ответственности были распределены между сторонами, а также все протоколы по совещаниям подписывались и сроки в них фиксировались. только так. Но проект это машина, которую если запустить то остановить потом тяжело. Она че то все равно молоть будет, только как часто бывает без управления перемалывает не то что нужно.
(2) срок поставлен, ответственный есть. срок нарушен, ответственному по ушам. если начинает рассказывать про космические корабли требуем заменить или повлиять в целях сохранения темпов по проекту и соответствия плану. если есть отчет и по отчету видно что сроки от совещания к совещанию нарушаются, то тут все становится ясно.
К тому же, кроме денежной мотивации есть еще и понятие человека слова. Дал слова, выполни. Нарушил слово нужно это четко обозначить и заострить на этом внимание окружающих. Мол смотрите, среди нас есть человек который за свои слова не отвечает. Его слова это ноль. Не так грубо но примерно. Человек кем бы он ни был начнет лезть под стол. Т.к. все тут красавцы, а он "нифига не дартаньян".

5. CheBurator 2712 11.06.10 18:13 Сейчас в теме

(3) да все понятно...

2. CheBurator 2712 11.06.10 17:43 Сейчас в теме

опять же. как правило - внедрение чего-то нового связано с формализацией процессов, в т.ч. и появление6м новых задач/обязанностей которые нужно выполнять будет. Про повышение ЗП сотрудникам - речи ясен пень нет. Мотивация - отсутствует. Руководстов тем не менее сильно "хочет" новую систему/возможности, !декларируя! что сотрудники будут делать что надо... Что делать в этом случае РП? при малейшей пробуксовке от сотрудников, которым это нафиг не надо...? тормозить проект чтобы куроводство мотивировало сотрудников...?

158. kazna2011 08.02.12 17:29 Сейчас в теме

я не понимаю как можно остановить проект. в среднем проекте задействовано порядка 3-5 сотрудников. каждому розданы задачи. один не справилася. машем палочкой и требуем чтобы все остановились!? это не реально.
проект не остановится, просто если речь идет о жестких сроках, какие бывают при выполнении гос.контрактов, то тут у нас появляется шанс сдвинуть срок вперед, при условии что ТЗ было составлено грамотно, и зоны ответственности были распределены между сторонами, а также все протоколы по совещаниям подписывались и сроки в них фиксировались. только так. Но проект это машина, которую если запустить то остановить потом тяжело. Она че то все равно молоть будет, только как часто бывает без управления перемалывает не то что нужно.
(2) срок поставле

4. gavril 44 11.06.10 18:08 Сейчас в теме

:D
Че - ФАКТ - НЕ ЧИТАЮТ!!!

6. 11.06.10 18:14 Сейчас в теме

(4) Читают! Но при определенных ударах в бубен. (бубен не пользователя)
Делаем так.
На совещании объявляем. Мол дамы и мадамы. С сего дня объявляем ОЭ! Шо? Опытную эксплуатацию я говорю! Аааа!
Правила простые. Мы выполняем обычные наши функции, но по инструкции. Если что не так, сообщаем в службу поддержки.
Оператору службы поддержки строго на строго запретить давать прямые ответы. Только ссылки на пункты инструкции. Само собой к этому моменту наши инструкции должны быть прописаны под процессы заказчика. Если это не так, пиши пропало.
Далее по факту инцидентов, идем к пользователю, но также забываем про прямые ответы. Молча подходим, слушаем вопрос, далее ищем по инструкции где пользователь мог допустить ошибку. Спрашиваем все ли пункты инструкции он выполнил.
Пользователь смотрим жалостливыми глазками, мол ну ее инструкцию, тыкни кнопочку чтобы все было чики пуки. А мы так гордо стоит и говорим ни ни. Открывай инструкцию тыкай по пунктикам. Он с горем пополам начинает тыкать по инструкции. И где то с раза 5-го перестает звонить в службу поддержки потому что понимает что быстрее заглянуть в инструкции.

9. CheBurator 2712 11.06.10 18:44 Сейчас в теме

(6) да, именно так и приходится... но при этом инструкции превращаются в монстров. причем желательно по принципу: Подлежащее-Сказуемое-ТОЧКА. Более сложные конструкции - не воспринимают...
.
проблемы не в этом. Проблемы в верхних этажах власти. За необлюдение инструкций - куроводство не дерет. За несоблюдение объемов продаж/оборотов - дерет. Поэтому манагеру - инструкции - пофиг. Будет делать как привык.
.
При этом куроводству всеми возможными способами доносится что выполнение инструкций в среднесрочной перспективе окупает затраченное на нее время и прочее и прочее - НЕА!!!!! важно чтобы СЕЙЧАС шли продажи, капало бабло. И вроде показываешь, обосновываешь - что если вот так сделать - тривиально можно повысить эффективность труда и прчее и прочее...
.
Проблема в том, что любая автоматизация - требует формализации процессов. формализация - это дисциплина. Дисциплина - это необходимость ее соблюдения. Это более формальные отношения к сотрудниками. куроводству надо больше напрягаться...

10. Ish_2 1112 11.06.10 18:50 Сейчас в теме

(9) Заметь , что главный смысл статьи :
ДОЛЖЕН БЫТЬ РП. Или : РП ДОЛЖЕН БЫТЬ.
А "формализация процессов" - штука , конечно, нужная и полезная. Но вторичная.

11. CheBurator 2712 11.06.10 19:02 Сейчас в теме

(10) не очень согласен. Формалиизация процессов - штука очень нужная. Понятно - кто что и когда должен делать. Легко относительно заменить. Понятно, что писать это все сложно и в большинстве случаев работают и без сильной формализации, НО! если косяк - ВИНОВАТЫХ НЕТ!!!!! а трахаться кому, исправляя косяки? как пример: две паллеты, разные поставки - палетные этикетки были перепутаны. палеты ушли не туда. так мало того- они еще и скомпанованы были ВПЕРЕМЕШКУ! рекламация приходит месяц спустя. Требуется все поменять задним числом. вопрос: как это сделать не нарушив раскладку по ГТД в выписанных документах для остальных клиентов (кроме этого ГТД в СЧФ должна соответсовать тому что в базе). - понятно, что это должно разложиться автоматом нормально - но это в том случае если нет других косяков...
.
и так - везде!
;-)

14. Ish_2 1112 11.06.10 19:18 Сейчас в теме

А я буду дудеть в свою дуду :
(11),(12),(13) красочно объясняют почему РП должен быть.

....И почему после окончания проекта РП должен остаться.

21. 12.06.10 16:32 Сейчас в теме

(10)

А "формализация процессов" - штука , конечно, нужная и полезная. Но вторичная.

ну зачем же так категорично.
В проектах до 100 сотрудников это может еще проканать. А вот когда речь идет о производствах на 1000 человек, там где тысячи различных операций и условий, без инструкций вы получите жутко затяжной проект и систему которая будет подсажена на аппарат искусственного дыхания в виде программистов на пабэгушках у бухгалтеров. типа "Ээээ Вася, падайди мне кнопочки нажать"
(14)

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

24. Ish_2 1112 12.06.10 16:49 Сейчас в теме

(21) Это старая полемика у нас с Чебуром : "Что главное и что второстепенное при автоматизации?".
Вырванные из этого контекста фразы в (10) воспринимаются как перехлёст - согласен.

7. CheBurator 2712 11.06.10 18:39 Сейчас в теме

(4) и спрашиваешь - почему вот так делаешь, в инструкции же написано - глазами луп-луп...

8. Ish_2 1112 11.06.10 18:39 Сейчас в теме

А хорошо написано !

12. CheBurator 2712 11.06.10 19:04 Сейчас в теме

с одной стороны - надо наказывать за косяки, с другой - вменяемого персонала не найти. Я например с трудом представляю как "автоматизировать" работу, которая выполянется по приницпу - я тут ткну, если все нормально то все нормально, а если ненормально то и хрен с ним... ;-)

15. Traas 78 11.06.10 19:59 Сейчас в теме

(12) (13) Интересно - много у Вас было проектов, в которых был АБСОЛЮТНО ВМЕНЯЕМЫЙ персонал?
Персоналу все эти автоматизации нафиг не нужны.
Проект может быть доведен до конца только в том случае, если в его результате кровно заинтересован спонсор проекта/ руководитель проекта СО СТОРОНЫ заказчика - все остальное (на мой взгляд) просто "освоение бюджета"

16. CheBurator 2712 11.06.10 20:19 Сейчас в теме

(15) Проектов - мало. Поэтому и интересно ПОНЯТЬ, как для себя понять - настроения и цели хакахчика.

13. CheBurator 2712 11.06.10 19:06 Сейчас в теме

тотально все усугубляется крайне низким уровнем персонала. При потребностях ДОСТАТОЧНО СИЛЬНОЙ АВТОМАТИЗАЦИИ. в итоге - абизяны за пультом атомной станции. 90% обвески "оборудования/кода" - защита от дурака.

23. 12.06.10 16:44 Сейчас в теме

(13)

в итоге - абизяны за пультом атомной станции. 90% обвески "оборудования/кода" - защита от дурака.

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

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

27. CheBurator 2712 12.06.10 20:55 Сейчас в теме

(23) прог пишет 90% обвески потому что проблема решается запросто, но на другом уровне, на который он не вхож. Например, можно взять вменяемого спеца с соответсвующей эффективностью - но он не будет бессловесной обизяной за 20-30 тыс. Например: можно запретить курение в рабочее время для складского персонала и тем самым получить дополнительныз три человеко-часа, а можно не запрещать и напрягать прога, чтобы все печаталось быстрее...

29. yumashev 12.06.10 21:39 Сейчас в теме

(27)

прог пишет 90% обвески потому что проблема решается запросто, но на другом уровне, на который он не вхож. Например, можно взять вменяемого спеца с соответсвующей эффективностью - но он не будет бессловесной обизяной за 20-30 тыс. Например: можно запретить курение в рабочее время для складского персонала и тем самым получить дополнительныз три человеко-часа, а можно не запрещать и напрягать прога, чтобы все печаталось быстрее...

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

33. CheBurator 2712 13.06.10 01:31 Сейчас в теме

(29) ".. Если организация не предусматривает процедуры улучшения своей деятельности или моя инициатива была оборвана, то в жопу эту организацию..." - угу... и после таких РП кто будет вытягивать полумертвый проект? и писать кучу обвески хоть чтобы что-то работало? - а? ;-)

37. yumashev 13.06.10 08:38 Сейчас в теме

(33)

- угу... и после таких РП кто будет вытягивать полумертвый проект? и писать кучу обвески хоть чтобы что-то работало? - а?

Если говорить за себя, то когда я был наемным РП, само собой писал заявление только когда уже довел проект до логического завершения. Причем предупреждал об этом сразу как только появлялся соответствующий настрой, посреди проекта. Чтобы люди могли начать искать замену.
Были и провалы. Куда ж без них ) Опыт - сын ошибок трудных.
Это правило внегласного кодекса чести профессионалов - довести проект до конца. Также как у главных бухгалтеров есть правило кодекса чести, перед уходом довести отчетный период. Свести дебет с кредитом :)

39. Ish_2 1112 13.06.10 11:21 Сейчас в теме

Посты (29),(30) вполне сойдут за набор лозунгов.
Прочитаем ;
" В рамках проекта РП царь и бог. И если генеральный директор попадает в зону проекта как участник и как лицо от которого требуются какие то действия, то он временно становится подчиненным РП. Это серьезно. Не шутки. "

А что ? Всё верно и просится на плакат.
Но :
"Просто в практике 1С я недавно. Раньше занимался внедрениями других программ и опыта поднакопил. Более 40 проектов. А войдя в практику 1С ужаснулся состоянию дел"

- и это иногое объясняет.
Всё еще впереди.

От себя же добавлю , что такое положение РП (царь и бог) возможно при внедрении оч. дорогих зарубежных пакетов и административного ресурса не нужно добиваться - ОН УЖЕ ЕСТЬ.
Провальность , правда, в таких проектах ничуть не ниже.

41. 13.06.10 13:27 Сейчас в теме

(39)

- и это иногое объясняет.
Всё еще впереди.

От себя же добавлю , что такое положение РП (царь и бог) возможно при внедрении оч. дорогих зарубежных пакетов и административного ресурса не нужно добиваться - ОН УЖЕ ЕСТЬ.
Провальность , правда, в таких проектах ничуть не ниже.

Вы реально думаете что от изменения программы ситуация как то меняется?
Это ошибка. От смены программы ничего не меняется. Люди они и в африке люди.
Ужаснулся я не от 1С и не от особенностей заказчиков. В малом бизнесе есть особенности но они больше упрощаются чем усложняют. Проблеме не в программе и не в заказчиках. А именно в том что в сообществе 1С до сих пор нет культуры внедрения.
Отдельные специалисты добившиеся успеха есть. Но знания не объединяются. В отличие от сообществ других программ.

50. Ish_2 1112 13.06.10 14:30 Сейчас в теме

(41)
В (39) речь не о смене программы как панацее, а о необходимости учитывать 1с-овские реалии :
В подаляющем числе случаев РП не имеет изначально административного ресурса - он вынужден его добиваться, лавировать и выкручиваться. ТАК ЕСТЬ.
А правильные заученные лозунги о том КАК ЭТО ДОЛЖНО БЫТЬ - чаще всего исходят от внедренцев зарубежных пакетов , действующих как правило в очень комфортных (по 1с-овским меркам) условиях. Вот я и предположил , что у автора поста (29) всё ещё впереди.

53. 13.06.10 15:19 Сейчас в теме

(50)

В (39) речь не о смене программы как панацее, а о необходимости учитывать 1с-овские реалии :
В подаляющем числе случаев РП не имеет изначально административного ресурса - он вынужден его добиваться, лавировать и выкручиваться. ТАК ЕСТЬ.

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

А правильные заученные лозунги о том КАК ЭТО ДОЛЖНО БЫТЬ - чаще всего исходят от внедренцев зарубежных пакетов , действующих как правило в очень комфортных (по 1с-овским меркам) условиях. Вот я и предположил , что у автора поста (29) всё ещё впереди.

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

30. Alav 13 12.06.10 22:05 Сейчас в теме

(23) Не согласен. Защита от дураков пишется потому что в случае косяка виноват не тот, кто допустил косяк, а программист, потому что "программа дала". И в случае экономии на з/п персонала, проще поставить защиту от дураков, чем разгребать последствия, потому что в любом случае пользователь сделает круглые глаза и скажет, что ему не объяснили, что так делать нельзя

35. yumashev 13.06.10 08:27 Сейчас в теме

(30)

Не согласен. Защита от дураков пишется потому что в случае косяка виноват не тот, кто допустил косяк, а программист, потому что "программа дала". И в случае экономии на з/п персонала, проще поставить защиту от дураков, чем разгребать последствия, потому что в любом случае пользователь сделает круглые глаза и скажет, что ему не объяснили, что так делать нельзя

О. Это ужасно! Мои слова не приняты за истину в последней инстанции! ))
Ваше право. Верить не верить. Я лишь говорю про свой опыт и находки.
Мне как программисту который зарабатывает на экономии времени проще написать инструкции чем расковырять программу. В инструкции записано что вот тут должна стоять галочка. И если сбой произошел потому что галочка не стоит. То причина тут не в программе, а в пользователе. И подзатыльник ставим пользователю. Чтобы в следующий раз галочку ставил.
Это правило позволяет добиться эффективности и снизить затраты.
Да, и в нем есть исключение. Если служба поддержки покажет что этот сбой возникает очень часто, и постоянные тыкания в инструкцию не дают результата, тогда можно дописать программу. Но такое происходит очень редко. За последний год у меня такого не было. Хотя проектов с полной технической поддержкой уже более 10-ка сделали.

38. Alav 13 13.06.10 10:54 Сейчас в теме

(35)Значит тебе повезло. У меня в жизни другие примеры. Когда руководитель филиала, где сидит такая девочка, которая постоянно косячит вместо того чтобы нанять нормальную девочку и заплатить ей чуть больше, держит "обезьяну" которая постоянно делает ошибки и при этом он считает, что тем самым он экономит деньги компании. А все попытки показать какая она дура и нафиг она здесь нужна, воспринимает в штыки типа это мои сотрудники и прошу мне не указывать кого мне увольнять/штрафовать. Ну а биг босы к этому относятся нейтрально. Продавать это не мешает (все косяки техподдержка исправляет) , все работают и все пределе. Ну а то что девочка косячит ... ну так ведь программа же дала, надо сделать так чтобы девочка не могла делать ошибки

17. Sergant 54 12.06.10 15:46 Сейчас в теме

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

20. Ish_2 1112 12.06.10 16:29 Сейчас в теме

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

22. 12.06.10 16:38 Сейчас в теме

(17)

ничего нового даже для тех, кто не занимался внедрением. не тратить время. минус.

Знаешь чем отличается успешный предприниматель от чахлого умника-ботаника? Тем что готов учиться и ставить под сомнения свои старые убеждения с учетом новой информации.
Я вижу кругом сплошные провалы проектов. Мы уже редко начинаем проекты с ноля. Как правило нам достаются уже начятые и заваленные проекты. Которые приходится вытаскивать из жопы. И причины завалов везде одни и те же. И как правило речь там идет о все знающих умниках, которые все знают, много чего обещали, но как только дошло до дел, тут же сдуваются и кидают людей.

18. Sergant 54 12.06.10 15:48 Сейчас в теме

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

19. 12.06.10 16:26 Сейчас в теме

да, именно так и приходится... но при этом инструкции превращаются в монстров. причем желательно по принципу: Подлежащее-Сказуемое-ТОЧКА. Более сложные конструкции - не воспринимают...

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

25. WKBAPKA 215 12.06.10 19:44 Сейчас в теме

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

26. Ish_2 1112 12.06.10 20:15 Сейчас в теме

(25) Вот-вот. Давайте сравним ответы.
Почему проект сдох ?
1. Куровед был Бог , барабанщик - плох
2. Куровед был плох, барабанщик - Бог.
(барабан- это клавиатура).

При всей условности и некорректности примера вероятность п.1 очень мала, хотя бы потому что
Бог с плохим барабанщиком в проект не полезет.

28. yumashev 12.06.10 21:33 Сейчас в теме

(25) Э не ребята. Так не пойдет. Вы пытаетесь ответственность за проект переложить на верха. Это не канает. В проекте есть всего одно лицо ответственное за его успех это РП. В рамках проекта РП царь и бог. И если генеральный директор попадает в зону проекта как участник и как лицо от которого требуются какие то действия, то он временно становится подчиненным РП. Это серьезно. Не шутки. Само собой не каждый ГД это признает, но по факту это так. РП рулит всем что нужно для обеспечения успеха задачи. И грамотный ГД будет от него ждать конкретных указаний что от него нужно.
Так что говорить что я РП распрекрасный, а вот директор лох это иллюзия. Лох в этом случае - РП, который не сумел выстроить отношения в проекте.

Но опять же, обсуждать эти риски это выходит за рамки статьи. Постараюсь продолжить серию статей на эту тему. Где расскроем и остальные риски.
Просто в практике 1С я недавно. Раньше занимался внедрениями других программ и опыта поднакопил. Более 40 проектов. А войдя в практику 1С ужаснулся состоянию дел. Реально тут культура внедрения просто атрофирована. Надо ее поднимать.

32. CheBurator 2712 13.06.10 01:30 Сейчас в теме

(28) совершенно все правильно!
(29) "...Любой человек который сумел взять бразды правления своей жизни в свои руки всегда видит ситуацию трезво, объективно и делает все что в его силах." - ДА! и причем с точки зрения владельца бизнеса - желательно должен это делать забесплатно! Реально - проекты стоят дорого. Реально - проекты желают выполянть с точки зрения владельцев бизнеса (мы не говорим про газпрос) - подешевле. - вот и все, в чем основные проблемы... И как бы ГД/владелец не говорил/декларировал готовность платить требуемые деньги/затраты - его вВСЕГДА ДУШИТ ЖАБА!

36. yumashev 13.06.10 08:33 Сейчас в теме

(32)

ДА! и причем с точки зрения владельца бизнеса - желательно должен это делать забесплатно!

Может быть тебе не повезло с владельцами. А может быть ты просто что то не так делаешь?
Я знаю много владельцев, т.к. сейчас кручусь в их кругах. Более здравых и рассудительных людей в этом кругу найти в сотни раз проще чем среди обычных.
Да, они за копейку готовы загрызть, но это не жадность, это ярость которая вызвана тем что им отвечать за людей и их семьи которым они платят ежемесячно деньги. И платить кому то за что то, мало поддающееся рациональному расчету с точки зрения получаемой прибыли это не в их правилах. Я слышал про эту особенность еще когда был рядовым программистом, но на ее четкое понимание ушло 5 лет.
И эти люди видят других на сквозь. Достаточно показать что твоя цель это результат, а не деньги. Он будет готов заплатить тебе в тридорога. Это уже проверялось много раз. Мы выставляем ценники на свои услуги в разы выше чем конкуренты. Но при выборе очень часто доверяют проект нам сразу или через пару месяцев, когда конкуренты облажаются ))

42. CheBurator 2712 13.06.10 13:28 Сейчас в теме

(36) видимо мы принципиально на разных типа конторах работаем ;-) Единственное, что хочу пожелать - это побыстрее расстаться с иллюзиями что владельцы бизнеса думают о сотрудниках и их семьях... Я раньше - тоже как ты был - рвался проект обязательно до конца доводить, бодался изо всех сил... да и счас регулярно в это сваливаюсь... ;-) А владельцам бизнеса как раз такие и нужны - "дурные до работы"... И буду тебе ласково улыбаться и все такое прочее.. но платить соответсвенно вложенной в работу души - нахрена? и так пашет, на одном энузиазме... и вся улыбчивость - она сразу пропадает, когда начинаешь обсуждать денежные вопросы...

Лучший

Ответить

44. 13.06.10 13:44 Сейчас в теме

(42)

видимо мы принципиально на разных типа конторах работаем smile;-) Единственное, что хочу пожелать - это побыстрее расстаться с иллюзиями что владельцы бизнеса думают о сотрудниках и их семьях

а ты уверен что иллюзии вижу я? :D
я как бы на этом рынке уже более 7 лет. на счету более 40 проектов. более 30 организаций. самый крупный на 1500 пользователей.
3 года уже как в своем бизнесе.
Да их забота это не сюсюканье. Да, они скорее пошлют тебя на 3 буквы и не будут ничего объяснять, потому что не видят в этом смысла. Их забота выражается в жесткости.
И да, я видел много руководителей которые быстро поднимали тех кто реально мог добиваться результатов. Но только казаться и быть это разное.
В общем сложно это. Тот рубеж когда работодатели и руководители казались мне козлами я перерос уже давно. А также то что в моих бедах виноваты все кроме меня. Это начальный уровень любого специалиста.
Так что кто тут видит иллюзии нужно еще подумать :)

47. 13.06.10 13:53 Сейчас в теме

(42)

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

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

31. kote 537 12.06.10 22:47 Сейчас в теме

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

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

.. но маленькие проекты все это может излишне усложнить - и удорожить.. Хотя если заказчику не жалко платить за эту работу - её всегда лучше делать. Вероятность провала сводится к минимуму.

34. yumashev 13.06.10 08:23 Сейчас в теме

(31)

.. но маленькие проекты все это может излишне усложнить - и удорожить.. Хотя если заказчику не жалко платить за эту работу - её всегда лучше делать. Вероятность провала сводится к минимуму.

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

168. tango 545 12.08.13 10:30 Сейчас в теме

(34) yumashev,

внедряем(!) БП Базовую в конторе с одним бухгалтером

(это я просто в рамочку повесил, ничего личного)

40. Alav 13 13.06.10 12:38 Сейчас в теме

Ну да, вот только директор/собственник/руководитель не даст тебе 100% власть. Нет на словах и на бумаге все красиво, но если подчиненные прибегут жаловаться к нему он махнет шашкой и все отменить (царь он или не царь?). Так что много зависит и от директора, точнее от желание отдать 100% власть и не позволяет себе вмешиваться в дела РП расставляя приоритеты и направления. Если это не так, то вероятность завершения проекта далека от 100% и тут все зависит от талантов РП.

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

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

43. 13.06.10 13:38 Сейчас в теме

Всем
Начался глупый спор о том что эти правила не спасают от всех рисков.
Кто спорит?
1. Да, если проект решено завалить на высшем уровне то не одни правила не спасут и не один РП не выстоит.
2. Да, если на предприятие упадет атомная бомба, то проекту не видать успешного заврешения.
3. Таких условия может быть много.

Однако!
Сколько случаев из 100 попадут под эти условия?
Я лишь говорю что это базовые правила управления проектами, которые помогают выруливать существенно большую часть проектов, даже при весьма сложных окружающих условиях.
И беда большинства провалов в том что эти базовые правила не выполняются.
Это не панацея от всех бед. Это лишь гарант успеха в большинстве возможных случаев.
Нужно лишь начать их выполнять. А рассуждать о том что может быть то и то, а еще вон то, и это ай ай ай как страшно. Ну рассуждайте. Ваше дело. Если хочется рассуждать. Кто ж мешает. Мне больше нравится делать. Делаю. Реально помогает.

45. Kamikadze 46 13.06.10 13:48 Сейчас в теме

Думаю, что здесь вопрос стоит в организации работы с клиентом. Все нюансы работы с работниками заказчика, все потребности нужно по максимуму "выудить" с заказчика перед началом работы над проектом.

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

46. CheBurator 2712 13.06.10 13:50 Сейчас в теме

Раз уж тут примеры приводили: приведу и я. Проект, идет туго, персонал - "старый", расп...и, привыкли к расхлябанности, если уволить половину и взять новых - и проект пойдет быстрее и ситуация стабилизируется. Тока вот - где этих новых взять? объект - в своей "зоне", среди таких же других объектов, на километры вокруг весь персонал вменяемый выбран. Вот и борешься с тяжелым наследием прошлого. Тривиальная трудовая дисциплина - ни в дугу... а владельцу - на словах мне даны куча прав, реально - ни одного "наказания" которые мною были инициированы - не исполнено... Но проект-то надо сделать! у нас же профессиональная гордость за несданные проекты...
.
А так конечно, культура внедрения/проектов - как отмечалось выше - ни в дугу.. Привыкли к сложившемуся образу 1С...

48. 13.06.10 14:04 Сейчас в теме

(46)

Проект, идет туго, персонал - "старый", расп...и, привыкли к расхлябанности, если уволить половину и взять новых - и проект пойдет быстрее и ситуация стабилизируется. Тока вот - где этих новых взять? объект - в своей "зоне", среди таких же других объектов, на километры вокруг весь персонал вменяемый выбран. Вот и борешься с тяжелым наследием прошлого. Тривиальная трудовая дисциплина - ни в дугу... а владельцу - на словах мне даны куча прав, реально - ни одного "наказания" которые мною были инициированы - не исполнено... Но проект-то надо сделать! у нас же профессиональная гордость за несданные проекты...

Могу только пособолезновать ))
Ну и рекомендовать налечь на инструкции и обучение. При дубовом персонале это единственный выход.

49. Alav 13 13.06.10 14:14 Сейчас в теме

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

51. WKBAPKA 215 13.06.10 14:41 Сейчас в теме

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

52. WKBAPKA 215 13.06.10 14:45 Сейчас в теме

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

54. 13.06.10 15:29 Сейчас в теме

Сочувствую. Только причем тут правила управления проектами и ситуация при которой вы пытаетесь впарить людям то что и не надо?
Это все равно что жаловаться на ноутбук который плохо помогает продать снег папуасу.
Я говорю о проектах которые нужны людям, но которые не могут быть реализованы в силу отсутствия базовых правил управления. Людям они нужны, они ходят синие от перегрузак и им нужна помощь. Но бравые специалисты наобещавшие золотые горы валят один проект за другим. Из-за того что считают себя шибко умными.
И эти руководители потом обращаются к нам. Мы смотрим на ситуацию и понимаем что все стандартно. Опять 25. Одно и тоже. Те же самые ошибки.

А когда система не нужна главному бухгалтеру или директору. То смысл эту систему создавать? Если она никому не нужны? Можно ли эту ситуацию назвать проектом? Это скорее игра в отмывание бабла. Это не проект.

55. CheBurator 2712 13.06.10 15:50 Сейчас в теме

(54) тоже верно. но видать у некоторых запасы бабла немерянные и могут отказываться от работы ;-)... проблема в том, что ВЗУ - вроде поняли, что дальше с тем багажом, который есть - двигаться будет трудно. НАДО ЧТО_ТО ДЕЛАТЬ. "Что-то" - это изменение сложившегося порядка вещей, как правило, связанное сдополнительными вложениями в инфраструктуру, в людей, в разделение сфер ответсвенности, в выстраивание иерархий (вертикальных/горизонтальных). И вот тут начинается самое интересное - поняте о том что надо что-то делать как-то ну.. эта... нивелируется необходимостью вложения бабла. причем СЕЙЧАС. с еще не до конца понятым эффектом в будущем. и болтаемся.. как говно в проруби... не видел еще ни одного проекта, который был "развивался" без денег... Персоналу - как правило - пофиг. работали же до этого... работали... зарплату получали.. а теперь - за те же деньги - придется работать по другому... - кому это надо? никому... мне что ли разрабатывать систему мотивации персонала? рассказывать как хорошо все будет? подымать самосознание? Не, конечно, на проекте с 5000 человек - там в команде проекта дохрена спецов может быть...

56. CheBurator 2712 13.06.10 15:57 Сейчас в теме

опять же - запуск проекта в работу - достаточно серьезное дело. зачастую ломающее привычные представления/сложившуюся практику работы. Персоналу на первых порах придется достаточно тяжело - РЕАЛЬНО ПРИДЕТСЯ НАПРЯГАТЬСЯ. - коренной вопрос: ЗАЧЕМ? ему зарплату повысят? ага, как же... наоборот - маячит призрак уволнения или необходимости РЕАЛЬНО РАБОТАТЬ... и проблемы не во "мне", проблемы - в управлении/мотивации персонала... вот где одна из основных проблем...

57. Alav 13 13.06.10 16:01 Сейчас в теме

А когда система не нужна главному бухгалтеру или директору. То смысл эту систему создавать? Если она никому не нужны? Можно ли эту ситуацию назвать проектом? Это скорее игра в отмывание бабла. Это не проект.

Из соседней ветки
По опыту если устраивает, но у соседа есть - то делаем как у соседа (90% случаев). Менталитет ларька.

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

58. 13.06.10 16:26 Сейчас в теме

Видимо я везунчик ))) Раз у меня все проекты проходят относительно ровно.
1. Да есть клиенты которые ни бум бум в ИТ и им нужно лижбы бухгалтер отвязался со своими отчетами в налоговую. Но тут все достаточно просто. Поставили программу, настроили минимальный функционал, дали инструкции, пару недель походили в гости, прошлись вместе по инструкциям, ответили на вопросы. Перевели на тех.обслуживание в штатный режим. Поехали!
2. Около 20% берут 1С чтобы кроме функций для налоговой еще и собирать информацию о состоянии дел. Но тут как правило или руководитель заинтересован, и он через нас дает дрозда другим, или главный бухгалтер. Но все совещания проходят с шумом, виден запал и желание решить проблемы.
3. Проекты когда заказал один, а потом делает другой которому это нафиг не надо встречаются как раз в больших конторах, где 1С и не пахло. Там да, РП кроме владения управлением и предметом деятельности, должен еще не хило разбираться в политологии, психологии и НЛП, дабы выруливать ситуации на грани фола. Но вот в 1С я как раз такого еще не встречал. Подобными проектами рулил на других продуктах, до 1С.

59. kosilov 276 13.06.10 16:51 Сейчас в теме

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

Прежде всего необходимо различать автоматизацию и реинжениринг бизнес процессов. Это крайне важно. Здесь я бы отметил следующее:
1. Нельзя автоматизировать вакуум. (Если Бизнес-процессы (далее БП) не формализованы, а как соледствие неустойчивы, имеют несколько произвольных вариаций то автоматизировать такой кисель не удастся)

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

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

Есть известный подход реинжениринга as is - to be. Суть которого заключается в том, что после этапа обследования прописывается две модели БП. As is модель - модель БП которая есть сейчас. To be - модель БП, которая должна быть после реинжениринга.
Для внедрения типовых необходимо строить модель As is - as soft - to be. Т.е. как бы добавляем еще одну модель - модель БП, которые заложены в ПО.
Построить модель as is невозможно не формализовав БП. Построить модель as soft невозможно не владея отличными знаниями по конфигурации и не имея опыта использования этой конфигурации на реальном предпритии.
При этом труднее всего построить модель as to be, так как эта модель должна находиться как бы на пересечении моделей существующей и програмной и при этом должна еще и быть оптимизирована. Кроме этого необходимо учесть "разрывы автоматизации" в местах где невозможно либо не целесообразно организовывать доступ работника к компьютеру (электронной системе).

Теперь можно четко разграничить автоматизацию и реинжениринг.
Возможности программы и эл.системы заключаются только в том, что:
1. Можно ввести и хранить первичные данные
2. Можно получить аналитические данные
3. Можно внести данные в одном месте, одним сотрудником и в одно время, а получить данные другим сотрудником в другом месте и в другое время.
Это конечно очень грубо, но факт в том, что ничего больше система делать не может, всё только в этих рамках.

Так вот, если процесс внедрения включает все аспекты, под автоматизацией подразумевается обеспечение коммуникации между эл.системой и человеком и соответствующей (адаптированной, обслуживающей) всю (или часть) систему БП, а под реинженирингом изменение системы БП. То можно четко разделить эти задачи по следующим критериям:
1. Задача реинжениринга - изменить модель БП организации с модели AS IS на модель TO BE. (Не думайте о компьютерах просто измените систему работы)

2. Задача автоматизации
a) Изменить программу с поддержки модели БП as soft на поддержку модели TO BE
b) Подготовить инструкции пользования программой для каждого рабочего места

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

Автоматизация - это обспечение такого состояния электронной системы, когда электронная система способна обслуживать модель TO BE (есть все необходимые формы для ввода и отчеты, система обслуживает весь необходимый объем полезной информации, обеспечены средства связи и т.д.), а также готов набор рукводств для каждого рабочего места о том как пользоваться системой.

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

Лучший

Ответить

60. 13.06.10 18:52 Сейчас в теме

(59) чувствуется желание сделать мир лучше :)
Вот только такими сложными формулировками можно этот мир перепугать до посинения.
В целом все написано верно. Вот только слишком сложно. Надо быть проще.
Тот пучок знаний который у тебя сейчас есть где то через годик еще подшлифуется, упростится и выстроится в очень красивую и стройную теория которую смогут применять люди. А пока слишком сложно. Такая каша у меня в голове была годика 2 назад :)
Сейчас все раскидалось по полочкам.
В этой статье я специально упустил многие требования различных стандартов управления по ИТ, я достаточно глубоко знаком с PMI, ITSM, рядом ГОСТов. Но те термины и глубина которые там используются нужны только для очень сложных проектов и очень продвинутых РП.
Тут же цель статьи не научить уму разуму грамотных РП и показать мою крутость и глубину знаний теорий. А просто акцентировать внимание на наиболее важных и простых правилах, исполнение которых уже позволит добиться успеха в 80% малых и средних проектах. Коих в день стартует и падает десятками.

Создал группу по развитию технологии внедрения 1С Предприятие. http://infostart.ru/community/groups/696/
Есть опыт в других программах. Видел красивые технологии. У 1С с этим явно проблемы.
Надо объединять усилия )

61. kosilov 276 13.06.10 21:46 Сейчас в теме

(60) Мне кажется, что ничего сложного я как раз не пишу. Сам не люблю, когда простые мысли обликают в сложные грамматические конструкции и используют редкоиспользуемые иностранные слова, для придания им большего веса. Автор в таком случае считает, что он выглядет более профессиональным и что говориться very cool.
Я писал просто из головы и без последующей правки и поэтому что-то может показаться немного перегружено. Идеи же, которые я изложил просты, но они базисные при внедрении (ИМХО).
По моему опыту внедрения и управленческого консультирования, именно непонимание разделения на автоматизацию и реинжениринг БП приводит к неудаче.
В комментариях кто-то написал, что формализовать БП не обязательно (интересно как этот человек внедрял ПО без формализации БП)
Естественно автоматизировать бух учет не сложно и прописывать модели БП там нет нужды. И не потому что эти модели не нужны, а потому, что там уже всё формализовано на уровне законов и подзаконных актов, а софт модель соответствует этой модели. Т.е. там нет реинжениринга БП и нет различий между софт моделью и моделью to be.
В управленческом же учете стандартов нет и там без формализации моделей не обойтись.
Так же в комментариях я прочитал о проблеме сопротивления изменениям со стороны персонала и мнение что РП должен это всё решать и чудесным образом вытягивать.

Вообще (ИМХО) проблема не внедренных решений прежде всего начинается с неправильного понимания внедренца того что хочет заказчик. Вернее непонимание уровня на котором он этого хочет и действие по стереотипу.
Заказчик может хотеть дополнительный отчет, внедренец понимает что для этого проще всего поставить типовую отраслевую конфу, а модель этой конфу в свою очередь требует перестроить работу все организации, а заказчик этого не понимает.
Иногда заказчик надеится и даже открыто говорит, что давайте мы подстроимся под программу, что мы якобы готовы к переменам и т.д. Но в такой организации скорее всего просто болото в котором вообще никто ничего понять не может. Именно поэтому заказчик не дорожит существующей системой БП, так как там просто нет системы.
Он хочет чтобы внедрив программу эта система появилась чудесным образом, и внедренец влазит (по неопытности) в это болото. А в этом болоте 90% реинжениринг (управленческий консалтинг) и только 10% автоматизации.

63. 13.06.10 22:39 Сейчас в теме

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

словарный запас у меня был емое. ты че. уши пухли в радиусе 100 метров.

а сейчас у меня осталось слов чуть чуть которыми могу описать все что есть в твоем сообщении:
1. описание процесса
2. оптимизация операционных затрат
3. программа
4. компьютер
5. регламент
6. человек

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

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

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

64. kosilov 276 14.06.10 10:36 Сейчас в теме

(63) Попал как-то один еврей на самолет с группой ученых. Интересуется значит када летят и чем занимаются. Ученый ему отвечает, что занимается теорией относительности, а летит на международный симпозиум по одноименной теме.
А что такое теория относительности, можешь объяснить, спрашивает еврей.
Ученый ему, значит, объясняет.
Не понял еврей объяснений и говорит, а можешь мне попроще объяснить.
Ученый ему объясняет по-проще.
Опять не понял еврей и попросил объяснить еще проще.
И так несколько раз.
Вот слушай, говорит ученый, я объясню тебе совсем просто.
Скажи, три волосины на голове это много или мало?
Конечно мало отвечает еврей.
А три волосины в супе?!...
Все относительно.
Улыбнулся ему еврей хитро и говорит - "И что вот с этой хохмой вы все 10 человек летите на симпозиум?"

62. Ish_2 1112 13.06.10 22:15 Сейчас в теме

Тихо поддержу (59). Упрек в сложности и непонятности (60) излишен.
Если простая мысль о том , что нужно разделять автоматизацию и реинжиниринг сложна для читателя , то читатель не РП и не автоматизатор.
Правда нужно указать, что на практике как правило автоматизация требует хотя бы частичного реинжиниринга и РП принимая решеие ввязываться в проект исходит совсем не из рекомендаций в (61). Его интересует прежде всего
1. бюджет
2. Адекватность упр.персонала , их истинные цели.

Причем п.1 - главный и определяющий.

73. Арчибальд 2709 16.06.10 10:27 Сейчас в теме

(59)(60) Если руководитель посчитает, что ему требуется реинжиниринг, то он обратится в реинжиниронговую фирму, и там с него сдерут немерянное бабло за консультации и столь же немерянное на покупку автоматизированной системы "To be" (как правило, эти фирмы знают, что "надо" внедрять, еще не знакомясь с заказчиком). Затем сумма возрастет еще в два-три раза за внедрение. Начнется текучка кадров. И долгий процесс восстановления разрушенного управления/учета.
ИначеЕслируководитель осознает, что автоматизация хаоса прводит к автоматизированному хаосу, он найдет и возьмет себе в штат квалифицированного автоматизатора, с помощью которого предотвратит развод фирмы на бабки и наведет порядок в своих бизнес-процессах таким способом, что "левых" внедренцев приглашать не придется. ИМХО.

75. 16.06.10 11:12 Сейчас в теме

(73)

ИначеЕслируководитель осознает, что автоматизация хаоса прводит к автоматизированному хаосу, он найдет и возьмет себе в штат квалифицированного автоматизатора, с помощью которого предотвратит развод фирмы на бабки и наведет порядок в своих бизнес-процессах таким способом, что "левых" внедренцев приглашать не придется. ИМХО.

Ох Арчибальд, Арчибальд. Вы случаем не из Москвы? )
Там я так понимаю еще есть шанс найти автоматизатора со знанием методов описания процессов и способов автоматизации того что описал.
А где их найти в регионах? Тем более в штат. Это знаете ли роскошь в наше время - раз. И в штате такие люди начинают киснуть, т.к. им постоянно нужна свежая кровь из новых проектов - два. Это люди хаоса и в условиях порядка они приживаются редко.
(72) Давай сделаем проще :) Лучше ткни ты пальцем хоть в одну инструкцию 1С которая описывала бы порядок действий и хотя бы типовую модель процессов организации. Чтобы ее можно было взять за основу, привести схему процессов к ситуации, и подправить операции. Дать пользователю и чтобы он смог начислить зарплату, оформить продажи, закрыть смены, передать деньги в кассу и т д.
Если найдешь, я тебя заплюсую с радости! 5й год ищу, и не по глазам она мне. Даже в в ПрофКейсе который позиционируется как база знаний внедренца. Даже там этим и не пахло.
А в других продуктах такие схемы есть. И имея опыт внедрения разностороннего ПО могу утверждать что 1. эти инструкции соответствуют нотациям типа BPMN или EPC, 2. пользователям по ним ориентироваться проще, 3. внедрять ПО при наличии этих инструкций в разы проще.
И опережая буйные возгласы о том что нотации моделирования это чушь, для русского менталитета они не подходят, спешу заверить что если идиоту дать в руки машину то он ее разобьет. и ведь дело то не в машине...

76. Арчибальд 2709 16.06.10 11:36 Сейчас в теме

(75) Ну видно же, что не из Москвы. Я вообще в сельской местности родился и живу :D
Конечно, иметь в штате готового РП - это роскошь. Однако ж в регионах и фирм реинжиниронговых нет. И цен/денег таких нет. Я о том и писал в своем посте, что реинжиниринг из (59) - это столичная утопия.
А вот найти думающего человека без регалий, сделать его личным консультантом с зарплатой на уровне, скажем, главбуха, дать ему благоустроенное служебное жилье в лизинг лет на пять - это реально даже для совхоза. Если уж умный руководитель решил заняться автоматизацией, такой человек ему дешевле обойдется, чем просто франча пригласить.

78. kosilov 276 16.06.10 14:13 Сейчас в теме

(73) Если руководитель осознает что ему нужен инжениринг, то скорее всего на уровне формализации БП в организации порядок. С другой стороны у руководителя полно своих дел (если он настоящий управленец, а не "фазан" или "свадебный генерал").
Поработав с иностранцами, я понял, что совковая тенденция экономии денег приводит, к тому, что вместо реальных услуг и товаров (при попытке сэкономить) ты получаешь фикцию. Всё имеет свою цену и чаще всего (не всегда конечно) это цена оправдана.
Консалтинг стоит дорого, но он действительно так стоит. Это время людей, которые учаться 90% времени, а только 10% времени консультируют. Эти люди имеют большой опыт, компания имеет свои разрботанные и оробованные технологии. Если бы Вы сами окунулись в этот бизнес то поняли бы что и почему стоит таких денег.
"Тётя Гала и моет и стирает и пылесосит и жрать готовит, зачем платить больше? Зачем покупать посудомоечную машину, пылесос и т.д.?" Такая у Вас логика?

Потом вы говорите, что эти фирмы знают to be и просто внедряют.
Каждая компания уникальна и модель to be тоже будет уникальной. Отдельные моменты могут быть типовыми, но это только моменты. В общем объяснять долго, если Вы окажитесь в шкуре руководителя, консультанта и внедренца (в разных шкурах), то сами всё поймете.
Ваше негативное отношение к внешним консультанта вызвана скорее всего тем, что в "постсовке" много "прохиндеев", которые "разводят фирмы и людей на бабки" при этом сами заказчики "клюют" на вёрдинг и пыль (по неопытности и скупости). Это пройдет со временем и "разводилы" окажутся без работы. Тем не менее сама отрасль консалтинга будет только развиваться.

81. Арчибальд 2709 16.06.10 15:32 Сейчас в теме

(78) "Консалтинг стоит дорого, но он того стоит..." Уточнение: очень редко он того стоит
"Это пройдет со временем..." С какой стати это пройдет? "Письма счастья" как 200 лет назад ходили, так и сейчас ходят
"В постсовке много прохиндеев..." Приведу чисто западноевропейский пример. Мой холдинг нанял английскую консалтинговую фирму для оценки совокупной стоимости владения (ТСО) IT. После заполнения 20 дюжин анкет, уплаты 20 килобаксов и трехмесячного ожидания мы получили рекомендацию перенести получасовой регламентный период (мы в обеденный перерыв выгоняли пользователей и базы бэкапили) на ночное время. Тогда, мол, ТСО IT у нас уменьшится на 4 мегарубля в год. Да за все время существования IT у нас на заводе (18 лет) мы еще столько не потратили...
Может у кого-то "окунание в этот бизнес" прошло по-другому. Опять же, в разных государствах ситуация, возможно, различная (а МКАД - это государственная граница). Я излагаю точку зрения россиянина, а не москвича.

82. tango 545 16.06.10 15:35 Сейчас в теме

(81) "Мой холдинг нанял английскую консалтинговую фирму для"
Рулёз, Арчи.... кого-то в "твоем" холдинге можно без ущерба нах :)

83. Арчибальд 2709 16.06.10 15:41 Сейчас в теме

(82) В личку загляни

89. kosilov 276 16.06.10 23:36 Сейчас в теме

(81) Всё верно, холинг развели на деньги. Но тут есть два вопроса, первый, это кто получил откат или не была ли это просто отмывка денег. Второй, как ставилась задача консалтинговой компании.
По большому счету, не важно как выполняется реинжениринг, консалтинговой ли компание ли или внедренцам либо силами самой компании. Важно, что есть понимание того, что необходим реинжениринг при автоматизации.
Внедренец может быть достаточно профессиональным и опытным, совмещать несколько специальностей. Быть и консультантам в области управления бизнес-процессами и программистом. Другое дело, что задачи разделяются на автоматизацию и реинжениринг и правильно оценивается объем работы.
Вот тут кто-то писал, что первым вопросом является бюджет.
В какой-то мере верно, но в целом - это не то с чего надо начинать.
Иначе получается например вы приходите к врачу с болезнью, а он Вам говорит а Вас как лечить хорошо или не очень? Соответственно подразумевая, что если денег дадите много,то он лечить будет Вас хорошо, а если мало, то не очень.
Или говорит Вам и того хуже: Мой час стоит $100, сколько часов вы хотите чтобы я вас лечил?
Пойдете лечиться к такому врачу?
Так и тут, приходите Вы к заказчику и спрашиваете: Сколько денег Вы готовы потратить?!
Теперь идем дальше. Допустим заказчик такой (с опытом работы с английской консалтинговой компанией :D )
Говорит хочу УПП.
Вы говорите, а сколько денег даете?
Он вас, а давайте я вам за час платить буду. Сколько часов Вам надо чтобы программу поставить?
Вы говорите программу поставить быстро, а вот внедрить ...
А он Вам: А как вы будете её внедрять? Вы скажет что надо делать, а все будут исполнять.
Вы говорите, ну надо инструкции написать на каждое рабочее место.
А он Вам, ны Вы же не первый раз внедряете, инструкции же уже писали, т.е. они у Вас есть, просто дайте нам их и всё. ;)
Вы говорите, ну поймите, что те инструкции, которые у нас есть не подойдут. У вас же компания другая.
А он, но программа же типовая. Значит и инструкции типовые. А то что компания у нас другая, так мы подстроимся. 8-)

Вот Вам и тупик диалога с таким подходом.

Но тут Вы говорите. Ладно пусть так. Это будет Вам стоить 5 килобаксов. А внедрим мы за три месяца.

А заказчик :o Вы чё совсем охренели? За программу я плачу, вы её прото ставите и за инструкции, которые Вы всем одни и те же даете хотите ПЯТЬ ТЫСЯЧ ДОЛЛАРОВ США?
Да идите Вы вон. Ищите других дураков ....

96. tango 545 17.06.10 10:52 Сейчас в теме

(89) "это кто"
в картинках это - здесь:
http://www.infostart.ru/public/71851/

90. hogik 443 17.06.10 01:30 Сейчас в теме

(81)
"Я излагаю точку зрения россиянина, а не москвича."©
Ну, вот, опять... :-(
Я - коренной москвич. Но моя точка зрения совпадает с Вашей, практически по всем Вашим высказываниям на данном ресурсе. Надеюсь, и по делам - совпадает...

93. Арчибальд 2709 17.06.10 07:23 Сейчас в теме

(90) Уточню: в существующем противостоянии я не участвую, зависти к москвичам не испытываю. Речь только о том, что "среда обитания" предприятий в Москве и регионах существенно различается. Соответственно и стереотип поведения руководителей (и поэтому, тех, кого они нанимают) совершенно разный.

99. hogik 443 17.06.10 14:47 Сейчас в теме

(93)
"Уточню: в существующем противостоянии я не участвую..."(с)
Угу. Вы, походя, его провоцируете утверждая в (81), что "москвич <> россиянин". А суть явления, на самом деле, сказана в (91) сообщении.

101. Арчибальд 2709 17.06.10 15:40 Сейчас в теме

(99) Да ничего я не провоцирую.
Давайте так: получить заявку контрагента, скомплектовать товар, выставить счет, проверить факт оплаты с учетом состояния взаиморасчетов, отгрузить товар. Бизнес-процесс в терминологии московских автоматизаторов. У нас это называется обслуживанием покупателя продавцом (в магазине). Ну не занимаемся мы этими бизнес-процессами, у нас это мелочь по сравнению с производственной сферой, соответственно, неактуально это. А тут я вижу разговоры о том, как выстроить этот "бизнес-процесс", чтобы навар увеличить. Да как его ни строй, все упрется в рекламу и т.п. Не принесет автоматизация пользы за счет оптимизации бизнес-процесса - если этот процесс работает, а не служит в основном для набивания карманов "менеджеров".
(100) 30 тыс. в Москве - это не средняя зарплата, а среднедушевой доход. © В. Познер
Офф: Кстати, когда Путин поднимал участковым врачам зарплату на 10 тыс., он на это и ориентировался - поднять з/п на 30-40 %. У нас получилось 350%, что уже явная глупость... Не может быть рациональным такое повышение з/п.

102. hogik 443 17.06.10 16:18 Сейчас в теме

(101)
Александр.
"Да ничего я не провоцирую"(с)
Беда в том, что МЫ, уже, даже не замечаем "провокаций". Я, пару лет назад, пытался обсуждать данный вопрос на этом ресурсе с другим, глубоко уважаемым мной, человеком. И больше не хочу этого делать...
Далее по СУТИ текста (101) сообщения - полностью согласен. Кроме темы "московских автоматизаторов". Я, всю свою жизнь, живу и работая в Москве. И не делаю "автоматизацию для набивания карманов". Зачем так примитивно обобщать людей по месту их проживания? Лично, меня это оскорбляет и обижает ооо-чень сильно... :-(

103. Арчибальд 2709 17.06.10 16:45 Сейчас в теме

(102) Я про набивание карманов автоматизаторов и не говорил. В (101) : либо бизнес-процесс работает нормально (на фирму) - тогда его автоматизация великого выигрыша не даст. Либо корявый бизнес-процесс работает на карман менеджера - тогда реинжиниринг и автоматизация (=упорядочение) принесут реальную пользу. Не увеличение прибыли, конечно, а уменшение убытков.

105. hogik 443 17.06.10 17:16 Сейчас в теме

(103)
"Я про набивание карманов автоматизаторов и не говорил."(с)
И я, вроде, не говорил. ;-) Мной было сказано "автоматизацию для набивания карманов" в продолжение Вашей формулировки - карманов "менеджеров". Я уже сказал, что наши мнения по сути "автоматизации", вроде, совпадают. Расхождения у нас совсем в другом... Завяжем?

106. 17.06.10 17:55 Сейчас в теме

(105) Off:
У всех комплексы как комплексы, у кого то полноты, у кого то маленьких гениталий, а у hogik'а комплекс москвича )))
hogik забей ты на эти высказывания ))) каждый человек это мешок стереотипов и сражаться против них можно до гроба. гораздо веселее просто включить режим наблюдения и стараться высматривать эти штуки. знаешь как забавно смотреть как сражаются 2 человека имеющих разную картину мира, т.к. к реальности ни одна из этих картин никак не относится, но каждый уверен что именно его картина мира и есть настоящая реальность, а другой дурак (и это мнение абоюдно). т.е. суть их спора не стоит и выеденного яйца но гонору и напалу хватило бы на маленькую мировую войнушку )))

160. Krasnyj 1288 13.03.12 16:51 Сейчас в теме

(101) Арчибальд,

Да ничего я не провоцирую.
Давайте так: получить заявку контрагента, скомплектовать товар, выставить счет, проверить факт оплаты с учетом состояния взаиморасчетов, отгрузить товар. Бизнес-процесс в терминологии московских автоматизаторов. У нас это называется обслуживанием покупателя продавцом (в магазине). Ну не занимаемся мы этими бизнес-процессами, у нас это мелочь по сравнению с производственной сферой, соответственно, неактуально это. А тут я вижу разговоры о том, как выстроить этот "бизнес-процесс", чтобы навар увеличить. Да как его ни строй, все упрется в рекламу и т.п. Не принесет автоматизация пользы за счет оптимизации бизнес-процесса - если этот процесс работает, а не служит в основном для набивания карманов "менеджеров".
_______________________________________________________________________________

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

161. Арчибальд 2709 14.03.12 07:51 Сейчас в теме

(160)

в таких отраслях, как алкоголь, фармация - эти моменты вообще являются ключевыми

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

162. Krasnyj 1288 14.03.12 11:41 Сейчас в теме

(161) Арчибальд, интересно, ей Богу. Даже википедия учит нас вот чему

Управляющие — бизнес-процессы, которые управляют функционированием системы. Примером управляющего процесса может служить Корпоративное управление и Стратегический менеджмент.
Операционные — бизнес-процессы, которые составляют основной бизнес компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение, Производство, Маркетинг и Продажи.
Поддерживающие — бизнес-процессы, которые обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка, АХО.

Поди, лжет?

91. kosilov 276 17.06.10 03:46 Сейчас в теме

(81) (90) Что там у Вас происходит?
У Вас граница по МКАД проходит или линия фронта?
В Москве просто всего больше и дуроков и денег и профессионалов.
Разделение труда (чудо специализация) до идиотизма доведена. Причем это веяние со стороны HR скорее всего.
У Вас есть профессия "установщик Windows" уже? ;)

А в остальном всё теже проблемы: "дураки и дороги".

94. Арчибальд 2709 17.06.10 07:26 Сейчас в теме

(91)

У Вас есть профессия "установщик Windows" уже?

Профессии нет, но мой эникейщик в этой "области компетенций" неплохой приработок имеет :D

97. tango 545 17.06.10 10:57 Сейчас в теме

(91) во-первых, "профессия" сервис-инженер - как бы фича 1сфраней.
во-вторых, "есть такая профессия - родину автоматизировать" (с - не знаю кто).
в-третьих - не по делу, но прикольно, афтара опять же не назову:
"есть такая профессия - родину зачищать"

65. 14.06.10 10:42 Сейчас в теме

Добавил публикацию с описанием и примером выполнения правила №3 http://infostart.ru/public/71738/

66. sss999 48 16.06.10 07:38 Сейчас в теме

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

67. Арчибальд 2709 16.06.10 08:19 Сейчас в теме

(66)

даже мне не делавшему ни одного внедрения

Может, потому и не дает?

68. 16.06.10 08:56 Сейчас в теме

(66) есть такой анекдот.

Сидит Мария и смотрит новости.
"...сегодня на одной из улиц города некий придурок гонял по встречной полосе и..."
Тут в дом заходит ее муж.
-Здравствуй, Вова!
-Привет, Маша. Представляешь, сегодня на дороге все, как будто пьяные. Вот идиоты(сорри), как сговорились, все едут по встречной полосе...

берем 2 факта:
1. те у кого есть опыт ставят плюсы
2. ты без опыта ставишь минус на основании собственного субъективного мнения что статья идиотская.
вывод сделаешь сам?

Получается что крутой РП никогда не сдвинет сроки сдачи проекта выставленные в первый раз,или он их совсем не выставляет?

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

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

тебе эта статья не поможет явно. скажем так. если у тебя не опыта РП то твой уровень можн условно обозначить 1/10.
прочитав книги по PMI, Agile, если будешь читать внимательно то можно предположить что твой уровень поднимится до 4/10.
и только после 3-го проекта твой уровень поднимится до 6/10. вот там то тебе эта статья и пригодится.
удачи! :)

69. Арчибальд 2709 16.06.10 09:11 Сейчас в теме

(68) По сути, ответ правильный. Но накал менторского пафоса великоват...

70. 16.06.10 09:32 Сейчас в теме

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

71. tango 545 16.06.10 10:05 Сейчас в теме

(0) последний заваленный при моем пассивном участии (кодер на договоре) проект - потому, что со стороны исполнителя рулил "руководитель проектов" от БиТа, который так о себе и говорил "я в программировании плохо...", а со стороны заказчика программисты были ... ну, мягко говоря - не на первых ролях.
Проблема, имхо, как раз в том, что на проектах этих программисты - те которые "специалист знакомый с программой, и тем как выглядят процессы при ее использовании" - не при делах.

72. tango 545 16.06.10 10:19 Сейчас в теме

(0) "те что идут в комплекте с 1С Предприятие. .... эти инструкции написаны программистами для программистов."
Ткни пальцем, автор. Предъявь инструкцию от 1С, напечатанную известной фирмой для пользователей, которая на самом деле - от прогов прогам.

79. kosilov 276 16.06.10 14:39 Сейчас в теме

(72) (75) (77) Ну что же Вы затыкали друг друга.
Tango, как мне кажется AY говорит о том, что коль в типовых конфигурациях заложены модели, то эти модели должны быть описаны как модели. Мы же имеет описание лишь подсистем и операций. Это разные вещи, разные подходы и уровни абстракций.
Если можно так выразится, в описании типовых конфигураций от 1С не хватает описание контекста, в котором это описание описано. Их описание это как ответы на вопросы, которые я не спрашивал и даже не догадыаюсь о том на какой вопрос это ответ.
Иногда (очень редко) описание содержит вводное, которое хоть как-то раскрывает область применения, но полноценной картинки не складывается. Чаще описывается пордок выполнения действий (как заполнить документ), реже есть намек на взаимосвязи документов. А необходимо такое описание, которое как бы описывало виртуальную компанию, со своей структурой, своими бизнес процессами и потом как система автоматизирует эти бизнес-проессы, кто, когда и как запоняет какие документы (вводит информацию), кто когда и как принимает решения на основании аналитики, что и как можно изменить в системе для обеспечения болшей совместимости с БП. Причем таких моделей должно быть несколько, так как любая конфигурация от 1С претендует на универсальность. Внедренец и управленец тогдо могли бы опираться на эти модели выбирая исходной такую, которая наиболее подходит конкретной организации.

Универсальность же конфигураций от 1С зачастую просто пагубна.
Представьте себе универсальную бортовую панель, которую можно поставить и на мопед и на машину и на самолет и на подводную лодку. Беру я эту панлель для своего авто и прежде чем я смогу её подключить, мне придется изучить что такое перескоп, тангаш, рули высоты, крен, вариатор, габаритные огни, угол атаки и т.д. Мне это для машины всё на Х не надо, а по другому я это панель просто не подключу.
После подключения начинается другое веселье. Машина отказывается ехать и после долгого копания в мануале оказвается, что она поедет только если нажать кнопку "Убрать шасси". Это была оказывается защита для самолет.
Потом я не могут открыть двери и выйти из машины, после изучения мануала, оказалось, что надо было нажать кнопку "убрать перескоп". В машине нет перескопа, но если бы он был (КАК НА ПОДВОДНОЙ ЛОДКЕ) то его надо было бы убрать и коль я использую эту универсальную панель, то должен его убирать. и т.д. и т.п.
При этом разрабатывая эту универсальную панель, компания разработчик не строила отдельных моделей для машины, мопеда, и самолета - она просто рассматривала некое обощенное транспортное средство, котрое может иметь переском, колеса, двигатель и т.д. И логику взаимодействия элементов тоже объединила в одну кучу.
Внедренец же должен сам узреть необходимую его компании модель в этом крокодиле с хвостом лапами и плавниками.
(пишу думая об УПП)

Лучший

Ответить

80. tango 545 16.06.10 15:10 Сейчас в теме

(79) образно и верно. но Вы нигде не сказали, что макулатура от 1с - это программисты для программистов. а у автора это в (0). мог бы "набраться смелости и признаться" (с - кто-то из местных сидельцев). а он привычно перевел стрелку