Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Скажите, пожалуйста, а что из этих «противопоказаний» специфично для СЭД и неприменимо к другим внедрениям?
lair, спасибо за вопрос!
Поскольку внедрение СЭД стоит рассматривать как частный случай более глобального явления — «автоматизация бизнесс-процессов на уровне компании», то, думаю, и перечень «противопоказаний», специфичных для СЭД, скорее частный случай сводного списка, составленного из данных смежных внедрений. По своему опыту участия в проектах внедрения и ERP- и CRM-систем могу сказать, что все эти «частности» встречались и там. Плюс добавлялись «предметные слабости» + особенности и глубина интеграции, например.
Есть еще одна история, которая встречается, пожалуй, вне зависимости от типа внедрения и носит скорее характер, как я его называю, «менеджерского вируса» — впихнуть в границы автоматизации не только типовые задачи (в случае ЭД — управления контентом), но и «все и вся», (начиная от управления проектами до создания кабинета виртуального обучения). Смотреть на творческое бурление умов невероятно захватывающе, но, на мой взгляд, важно это корректно и вовремя остановить, обсудив «чуждые требования» и порекомендовав «пылесосить все-таки пылесосом». И тут уже то самое волшебное чувство доверия между сторонами, когда открыто и честно, без «ванильных» ожиданий можно все обсудить и договориться, помогает конструктивно договориться.
Поскольку внедрение СЭД стоит рассматривать как частный случай более глобального явления — «автоматизация бизнесс-процессов на уровне компании», то, думаю, и перечень «противопоказаний», специфичных для СЭД, скорее частный случай сводного списка, составленного из данных смежных внедрений. По своему опыту участия в проектах внедрения и ERP- и CRM-систем могу сказать, что все эти «частности» встречались и там. Плюс добавлялись «предметные слабости» + особенности и глубина интеграции, например.
Есть еще одна история, которая встречается, пожалуй, вне зависимости от типа внедрения и носит скорее характер, как я его называю, «менеджерского вируса» — впихнуть в границы автоматизации не только типовые задачи (в случае ЭД — управления контентом), но и «все и вся», (начиная от управления проектами до создания кабинета виртуального обучения). Смотреть на творческое бурление умов невероятно захватывающе, но, на мой взгляд, важно это корректно и вовремя остановить, обсудив «чуждые требования» и порекомендовав «пылесосить все-таки пылесосом». И тут уже то самое волшебное чувство доверия между сторонами, когда открыто и честно, без «ванильных» ожиданий можно все обсудить и договориться, помогает конструктивно договориться.
Как говаривал мой шеф, «если пытаться автоматизировать бардак — на выходе получится автоматизированный бардак».
Quiz, поддерживаю Вас на 200%! В этом и различие в «голодном» и «грамотном» подходе)) Кто-то из Исполнителей радуется, что Заказчик испытывает невероятный аппетит и хочет многого. При этом получает на выходе проект, сдать который невозможно даже теоритически, поскольку результат ни померить, ни ощутить. А кто-то пусть и фрустрирует Заказчика «противопоказаниями», но при этом получает благодарного ПАРТНЕРА, потому что сразу объяснил и отказался делать «все, везде и вчера». Поделился, что стоит наладить ДО внедрения, о чем подумать, где порядок навести. Ведь асфальт тоже почему-то не везде хорошо держится!)))) Спасибо за мнение! Успехов!
Когда открыл статью, надеялся прочитать что-то более конкретное, но увы. Стандартное «зрелость компании должна соответствовать уровню технологии» и прочее бла-бла-бла.
Перечисленные Вами противопоказания с одинаковым успехом можно распространить на любой процесс вообще.
Не надо тратить деньги на офисный туалет, попробуйте обойтись ведром в темной комнате.
Перечисленные Вами противопоказания с одинаковым успехом можно распространить на любой процесс вообще.
Не надо тратить деньги на офисный туалет, попробуйте обойтись ведром в темной комнате.
Yurich, да, Вы правы! Об этом как раз написала выше, действительно список «универсален».
Я, так уж вышло, сейчас одной ногой на пороге очередного внедрения СЭД на очередном месте работы.
Могу сказать, что редок тот день, когда ко мне не подходят коллеги и не спрашивают, когда же начнем (не начинаем в числе прочего из-за отсутствия СЭД, такая вот рекурсия, документы лежат без движения в неизвестных местах, сроки согласования срываются и т.п.)
Но тем не менее, совет делать все средствами мсофиса великолепен. Типа, если не хотите внедрять готовую СЭД, напишите СЭД самостоятельно, используя непригодные для этого инструменты.
Я, помнится, ржал, когда в одной из контор увидел, как граждане, пользуясь примерно такими, как у Вас, рекомендациями, вместо внедрения чего-то вроде 1С: Предприятия, решили, что куда веселее держать в штате программистов числом 6 штук, и создать аналог на связке пиратской Дельфи и пиратского MS SQL-сервера.
Система писалась два года представляла собой изящный набор костылей, подпорок и синей изоленты. Я приперся к владельцу заведения, показал ему две цифры: зарплата команды программистов за два года с учетом всевозможных отчислений (налоги, пфр и так далее), аренды офисных помещений для них, покупки компьютеров для них и всего остального — с одной стороны и стоимость внедрения 1С: Предприятия с кастомайзом в необходимом объеме и дальнейшим саппортом. Тему продолжения работ по самописному барахлу свернули в течение недели.
Как я понимаю, Вы предлагаете всем прогуляться по этим граблям еще раз: давайте вы сами сделаете плохо, потратите время и деньги, накопите массу негативного опыта, наступите на все грабли, на которые наступают разработчики коммерческих СЭД еще до того, как начинают продавать первую версию своего продукта, а уж потом, когда контора потратит кучу ресурсов на заведомо плохое решение, можно будет и потратить небольшую копеечку на готовое решение, которое, вполне возможно, уже из коробки окажется лучше того, что создавалось местными кулибиными долгие годы.
Могу сказать, что редок тот день, когда ко мне не подходят коллеги и не спрашивают, когда же начнем (не начинаем в числе прочего из-за отсутствия СЭД, такая вот рекурсия, документы лежат без движения в неизвестных местах, сроки согласования срываются и т.п.)
Но тем не менее, совет делать все средствами мсофиса великолепен. Типа, если не хотите внедрять готовую СЭД, напишите СЭД самостоятельно, используя непригодные для этого инструменты.
Я, помнится, ржал, когда в одной из контор увидел, как граждане, пользуясь примерно такими, как у Вас, рекомендациями, вместо внедрения чего-то вроде 1С: Предприятия, решили, что куда веселее держать в штате программистов числом 6 штук, и создать аналог на связке пиратской Дельфи и пиратского MS SQL-сервера.
Система писалась два года представляла собой изящный набор костылей, подпорок и синей изоленты. Я приперся к владельцу заведения, показал ему две цифры: зарплата команды программистов за два года с учетом всевозможных отчислений (налоги, пфр и так далее), аренды офисных помещений для них, покупки компьютеров для них и всего остального — с одной стороны и стоимость внедрения 1С: Предприятия с кастомайзом в необходимом объеме и дальнейшим саппортом. Тему продолжения работ по самописному барахлу свернули в течение недели.
Как я понимаю, Вы предлагаете всем прогуляться по этим граблям еще раз: давайте вы сами сделаете плохо, потратите время и деньги, накопите массу негативного опыта, наступите на все грабли, на которые наступают разработчики коммерческих СЭД еще до того, как начинают продавать первую версию своего продукта, а уж потом, когда контора потратит кучу ресурсов на заведомо плохое решение, можно будет и потратить небольшую копеечку на готовое решение, которое, вполне возможно, уже из коробки окажется лучше того, что создавалось местными кулибиными долгие годы.
Yurich, в Вашем случае «ножного» согласования одно спасение — приделать документам «быстрые ноги», что означает заиметь замотивированного Заказчика. Вот пример из практики: крупное промышленное предприятие со штатом пользователей на 1-ю очередь внедрения 200 пользователей, выбрали систему, согласовали внедрение, посетили 2 региональных референс-клиента, включая переговоры с вендором — за 1,5 (!) месяца. Стоял жесткий срок, у процесса был влиятельный лидер, в компании НЕ БЫЛО СЭД до этого.
А компании, о которых Вы говорите, мы тоже встречаем ежедневно. И «реанимируем» проекты от подпорок в том числе. Как и писала в ответах всем активным и думающим читателям, каждой задаче — адекватный инструмент. Если в компании 15 чел, среди которых в согласованием документов занимается 3, а документов к согласованию, к пример, в год не больше 100, смысла ставить им СЭД — нет, согласуйте документы в том же Dropbox на здоровье и будьте счастливы)
А компании, о которых Вы говорите, мы тоже встречаем ежедневно. И «реанимируем» проекты от подпорок в том числе. Как и писала в ответах всем активным и думающим читателям, каждой задаче — адекватный инструмент. Если в компании 15 чел, среди которых в согласованием документов занимается 3, а документов к согласованию, к пример, в год не больше 100, смысла ставить им СЭД — нет, согласуйте документы в том же Dropbox на здоровье и будьте счастливы)
Простите, я не верю в существование компаний, где число согласуемых документов в год — менее сотни.
И кроме того, я плохо понимаю рекомендацию использовать дропбокс в бизнес-процессах вообще и применительно к согласованию документов в частности.
Документы даже в большем объеме можно согласовывать и с бегунками на бумаге, делов-то. Причем даже более успешно, нежели через дропбокс, ибо согласование документа это в первую очередь однозначное фиксирование факта, что должностное лицо ознакомилось с документом и одобрило его содержимое. Причем версия содержимого документа фиксируется, что исключает ситуацию, что от того документа, который подписывал руководитель, остается неизменной только страница с его подписью.
Вообще не представляю, кстати, как дропбокс способен помочь решить даже эту задачу (а еще ведь есть маршруты согласования, матрицы замещения и так далее).
Создается печальное впечатление, что, давая такие рекомендации (мс-офис, дропбокс и тп) Вы вообще плохо представляете себе продукта, который внедряете.
Что лично для меня даже и неплохо.
Спросят меня, а почему не доксвижн — радостно отвечу, что сами внедренцы рассматривают альтернативой ему мсофис и дропбокс, покажу Вашу статью, и вопросы ко мне снимутся.
И кроме того, я плохо понимаю рекомендацию использовать дропбокс в бизнес-процессах вообще и применительно к согласованию документов в частности.
Документы даже в большем объеме можно согласовывать и с бегунками на бумаге, делов-то. Причем даже более успешно, нежели через дропбокс, ибо согласование документа это в первую очередь однозначное фиксирование факта, что должностное лицо ознакомилось с документом и одобрило его содержимое. Причем версия содержимого документа фиксируется, что исключает ситуацию, что от того документа, который подписывал руководитель, остается неизменной только страница с его подписью.
Вообще не представляю, кстати, как дропбокс способен помочь решить даже эту задачу (а еще ведь есть маршруты согласования, матрицы замещения и так далее).
Создается печальное впечатление, что, давая такие рекомендации (мс-офис, дропбокс и тп) Вы вообще плохо представляете себе продукта, который внедряете.
Что лично для меня даже и неплохо.
Спросят меня, а почему не доксвижн — радостно отвечу, что сами внедренцы рассматривают альтернативой ему мсофис и дропбокс, покажу Вашу статью, и вопросы ко мне снимутся.
yurich
А зря, это малый/микро бизнес и нижний сегмент SMB — адекватная основа экономики в современном мире. Вопрос, готовы ли такие компании на серьезный проект СЭД, и нужен ли им СЭД в классическом понимании? Вероятно и там и там «нет».
Отличный инструмент для нижнего сегмента SMB, по крайней мере если сравнивать с пересылкой файлов по почте (электронной)
Смотрите, здесь же вопрос не в том, что прикладные инструменты есть аналог коммерческой платформы СЭД. На самом деле странно что Вы сделали такой вывод, ведь четко написано что внедрять СЭД в компанию из 15 человек, да даже из 50, вероятно имелось ввиду классический проект с внешним подрядчиком на коммерческой платформе, согласитесь, как минимум странно. Как минимум с точки зрения затрат. В этих случаях либо строим процессы на основе того, что под рукой (тот же офис и дропбокс, почему нет?), либо существует класс saas-ных недорогих вещей. Аналог этих вещей также можно развернуть локально. Кто станет инвестировать с ходу как минимум сотни тысяч рублей в таких условия в классический проект СЭД (directum/DocsVision/1C)?? Или как минимум миллионы для Documentum/OpenText/FileNet? И зачем он в такой ситуации?
А на самом деле четкая и адекватная оценка, что проект по СЭД не панацея от всех бед и не всем он нужен. Но это очевидно.
я не верю в существование компаний, где число согласуемых документов в год — менее сотни
А зря, это малый/микро бизнес и нижний сегмент SMB — адекватная основа экономики в современном мире. Вопрос, готовы ли такие компании на серьезный проект СЭД, и нужен ли им СЭД в классическом понимании? Вероятно и там и там «нет».
я плохо понимаю рекомендацию использовать дропбокс в бизнес-процессах вообще и применительно к согласованию документов в частности
Отличный инструмент для нижнего сегмента SMB, по крайней мере если сравнивать с пересылкой файлов по почте (электронной)
что сами внедренцы рассматривают альтернативой ему мсофис и дропбокс, покажу Вашу статью, и вопросы ко мне снимутся
Смотрите, здесь же вопрос не в том, что прикладные инструменты есть аналог коммерческой платформы СЭД. На самом деле странно что Вы сделали такой вывод, ведь четко написано что внедрять СЭД в компанию из 15 человек, да даже из 50, вероятно имелось ввиду классический проект с внешним подрядчиком на коммерческой платформе, согласитесь, как минимум странно. Как минимум с точки зрения затрат. В этих случаях либо строим процессы на основе того, что под рукой (тот же офис и дропбокс, почему нет?), либо существует класс saas-ных недорогих вещей. Аналог этих вещей также можно развернуть локально. Кто станет инвестировать с ходу как минимум сотни тысяч рублей в таких условия в классический проект СЭД (directum/DocsVision/1C)?? Или как минимум миллионы для Documentum/OpenText/FileNet? И зачем он в такой ситуации?
Создается печальное впечатление, что, давая такие рекомендации (мс-офис, дропбокс и тп) Вы вообще плохо представляете себе продукта, который внедряете.
А на самом деле четкая и адекватная оценка, что проект по СЭД не панацея от всех бед и не всем он нужен. Но это очевидно.
Про Директум за сотни тысяч рублей Вы хорошо сказали, спасибо. Сотни тысяч это WSS Docs скорее всего, директум это уже миллионы рублей.
А документум — десятки миллионов.
Я просто и то и другое внедрял, цены как бы в инвойсах видел, а не в красивых табличках на сайте про «у нас все дешево».
Про саас согласен, это для небольшой компании выход (но можно, например, и опенсорс/фривер раскопать).
А вот дропбокс — нет. Он вообще не для этого.
Уже тупо в связи отсутствием концепции маршрутов согласования документа.
А документум — десятки миллионов.
Я просто и то и другое внедрял, цены как бы в инвойсах видел, а не в красивых табличках на сайте про «у нас все дешево».
Про саас согласен, это для небольшой компании выход (но можно, например, и опенсорс/фривер раскопать).
А вот дропбокс — нет. Он вообще не для этого.
Уже тупо в связи отсутствием концепции маршрутов согласования документа.
yurich
Ну я собственно и написал «как минимум сотни», так сказать, делая запас. В моей практике также большинство проектов за пределами планки 1 млн рублей, но были и за 0,5 млн: для 25 пользователей со стандартными процессами уложится при желании можно. Поэтому написал «как минимум». Для документума сам не встречал случаев меньше 30 млн, но предположил что они могут быть, написав, как минимум.
У Вас какое-то предубеждение относительно Дропбокса. Согласен, нетиповое средство, но мы как раз и используем, очень удобно. Но как говорится, «на вкус и цвет..»
Извините, а о каких концепциях маршрутов вообще речь в компаниях с 15, 20, 30 людьми? В таком масштабе предприятия эти понятия если и уместны, то они сугубо в решены на неформальном уровне — в таком коллективе что то организовывать, чтобы как то контролировать и подбирать маршруты просто нецелесообразно. Там два, от силы три маршрута всегда и маршрутизация оперативно решается сама по себе.
Про Директум за сотни тысяч рублей Вы хорошо сказали, спасибо. Сотни тысяч это WSS Docs скорее всего, директум это уже миллионы рублей.
Ну я собственно и написал «как минимум сотни», так сказать, делая запас. В моей практике также большинство проектов за пределами планки 1 млн рублей, но были и за 0,5 млн: для 25 пользователей со стандартными процессами уложится при желании можно. Поэтому написал «как минимум». Для документума сам не встречал случаев меньше 30 млн, но предположил что они могут быть, написав, как минимум.
А вот дропбокс — нет. Он вообще не для этого.
Уже тупо в связи отсутствием концепции маршрутов согласования документа.
У Вас какое-то предубеждение относительно Дропбокса. Согласен, нетиповое средство, но мы как раз и используем, очень удобно. Но как говорится, «на вкус и цвет..»
Извините, а о каких концепциях маршрутов вообще речь в компаниях с 15, 20, 30 людьми? В таком масштабе предприятия эти понятия если и уместны, то они сугубо в решены на неформальном уровне — в таком коллективе что то организовывать, чтобы как то контролировать и подбирать маршруты просто нецелесообразно. Там два, от силы три маршрута всегда и маршрутизация оперативно решается сама по себе.
Yirich,
А что в этом такого плохого? В фундаментальном решении закрывать свои потребности собственными силами написав систему условно с нуля? Ваш пример говорит только о том, что пойдя на такой шаг не удалось в данном конкретном примере добиться качественного результата. Почему так случилось? Да причин может быть много: плохие программисты, плохая организация работ по развитию и написанию функционала, организационные проблемы компании. Все горазды судить о тех или иных проблемах не особо вдаваясь во все их причины. Думаете все «самописные» затеи плохи? Вот Вам контрпример, есть в открытом доступе, при желании можно найти: крупнейшая компания по выручке в Новосибирске, крупнейшая в России в своем сегменте: Катрен. Издревле практически все информационные системы у них самописные, огромный штат разработчиков, причем до сих пор, насколько мне известно. При этом, также в открытом доступе есть высказывания руководства компании о роли ИТ в успехи их бизнеса. Можно ли было в их случае строить все системе на базе платформ высокой степени готовности? Да, наверняка, технически это было осуществимо. Но вот с точки зрения инвестиций, отдачи от них, и рисков того или иного подхода — вопрос то очень спорный. У меня нет данных относительно статистики «успешности» проектов с самописными системами, но пару лет назад натыкался на статистику по проектам на коммерческих платформах — в мире не более 30% внедрений считаются полностью успешными. Как вы думаете, какой процент «достаточно успешных»? Какой процент в России? Как в «самописках», так и в платформенных проектах есть риски недостижения качественного результата, везде высокие, в самописках вероятно выше риски. Это первое. Второе в том, что рассуждая о теме затрат на содержание 6 веселых программистов и как то сравнивая это с коммерческим проектом, вы почему то ( изначально совершенно справедливо сделали упор на дорогое содержании братии разработчиков, что понятно), совершенно обошли внимание тот факт, что вообще то содержание команды у себя внутри это opex'ы (судя по всему порядка 0,5 млн в месяц + -в зависимости от региона и налоговой практики компании), отдача от деятельности которых наступает (если все хорошо) через 3-6 месяцев с начала написания системы (при этом наверняка эти 6 человек не только этой системой в компании занимаются). Коммерческий проект в классическом стиле — это немалые capex'ы на старте + те же операционные затраты во времени (соглашусь, эти opex'ы вероятно намного меньше чем кушают 6 разработчиков, хотя не всегда). В этом случае отдача также возникает примерно в сопоставимый срок. Поэтому что и с чем Вы сравнивали? Двухлетние opex'ы в размере 12 млн рублей (это если программисты только этим и занимались) с одной стороны, а что было на другой чаше весов? Ведь например capex даже в размере 6 млн не факт что лучше ежегодных opex'ов в те же 6 млн, если рассматривать контекст (риски нового внедрения, зависимость от вендора и подрядчика, тут то программисты рядом сидят). Поэтому Ваш пример на текущий момент показывает лишь то, что в конкретном случае самописка возможно была плохо написана, и не 100% факт что решение на 1С: Предприятии, ровно как и на любой другой платформе, было бы лучше. Вы же не станете утверждать что все самописные системы плохие? Также Вы наверняка не станете утверждать что все коммерческие внедрения успешные.
решили, что куда веселее держать в штате программистов числом 6 штук, и создать аналог на связке пиратской Дельфи и пиратского MS SQL-сервера.
Система писалась два года представляла собой изящный набор костылей, подпорок и синей изоленты. Я приперся к владельцу заведения, показал ему две цифры: зарплата команды программистов за два года с учетом всевозможных отчислений
А что в этом такого плохого? В фундаментальном решении закрывать свои потребности собственными силами написав систему условно с нуля? Ваш пример говорит только о том, что пойдя на такой шаг не удалось в данном конкретном примере добиться качественного результата. Почему так случилось? Да причин может быть много: плохие программисты, плохая организация работ по развитию и написанию функционала, организационные проблемы компании. Все горазды судить о тех или иных проблемах не особо вдаваясь во все их причины. Думаете все «самописные» затеи плохи? Вот Вам контрпример, есть в открытом доступе, при желании можно найти: крупнейшая компания по выручке в Новосибирске, крупнейшая в России в своем сегменте: Катрен. Издревле практически все информационные системы у них самописные, огромный штат разработчиков, причем до сих пор, насколько мне известно. При этом, также в открытом доступе есть высказывания руководства компании о роли ИТ в успехи их бизнеса. Можно ли было в их случае строить все системе на базе платформ высокой степени готовности? Да, наверняка, технически это было осуществимо. Но вот с точки зрения инвестиций, отдачи от них, и рисков того или иного подхода — вопрос то очень спорный. У меня нет данных относительно статистики «успешности» проектов с самописными системами, но пару лет назад натыкался на статистику по проектам на коммерческих платформах — в мире не более 30% внедрений считаются полностью успешными. Как вы думаете, какой процент «достаточно успешных»? Какой процент в России? Как в «самописках», так и в платформенных проектах есть риски недостижения качественного результата, везде высокие, в самописках вероятно выше риски. Это первое. Второе в том, что рассуждая о теме затрат на содержание 6 веселых программистов и как то сравнивая это с коммерческим проектом, вы почему то ( изначально совершенно справедливо сделали упор на дорогое содержании братии разработчиков, что понятно), совершенно обошли внимание тот факт, что вообще то содержание команды у себя внутри это opex'ы (судя по всему порядка 0,5 млн в месяц + -в зависимости от региона и налоговой практики компании), отдача от деятельности которых наступает (если все хорошо) через 3-6 месяцев с начала написания системы (при этом наверняка эти 6 человек не только этой системой в компании занимаются). Коммерческий проект в классическом стиле — это немалые capex'ы на старте + те же операционные затраты во времени (соглашусь, эти opex'ы вероятно намного меньше чем кушают 6 разработчиков, хотя не всегда). В этом случае отдача также возникает примерно в сопоставимый срок. Поэтому что и с чем Вы сравнивали? Двухлетние opex'ы в размере 12 млн рублей (это если программисты только этим и занимались) с одной стороны, а что было на другой чаше весов? Ведь например capex даже в размере 6 млн не факт что лучше ежегодных opex'ов в те же 6 млн, если рассматривать контекст (риски нового внедрения, зависимость от вендора и подрядчика, тут то программисты рядом сидят). Поэтому Ваш пример на текущий момент показывает лишь то, что в конкретном случае самописка возможно была плохо написана, и не 100% факт что решение на 1С: Предприятии, ровно как и на любой другой платформе, было бы лучше. Вы же не станете утверждать что все самописные системы плохие? Также Вы наверняка не станете утверждать что все коммерческие внедрения успешные.
Простите еще раз, но Вы как-то прекрасно считаете. В нашей стране, насколько я помню, чтобы заплатить рубль работнику, компания должна продать добра на 1.87 рубля.
То есть, при зарплате программистов в 60тр (те самые 0.5 млн в месяц) надо реально расстаться с почти миллионом рублей в тот же месяц чисто для обеспечения их зарплатой, ага?
Далее: на одно рабочее место надо бы отвести ну пусть жлобские пять квадратных метров офисной площади (реально, конечно, больше). Итого — 30 метров. Возьмем гуманные 15тр за метр в год, получим еще полляма в год.
Не забудем про транзакционную нагрузку на эйчар и пэйролл, не выпустим из виду обеспечение затратного подразделения офисной мебелью и вычтехникой, дополним все это пониманием, что реально на коллектив из 6 человек мы получаем работу 5.5, т.к. еще половина человеко-года это оплаченные отпуска.
И приходим к пониманию, что коллектив из шести человек реально нам стоит около 7 миллионов рублей ежегодно.
Как Вы думаете, смогу я коробку плюс кастомайз плюс саппорт купить дешевле и отнести все это на себестоимость плюс еще со всего, кроме коробки (а в ряде случаев и с нее) возместить НДС?
Я так думаю, что запросто.
Кроме того, есть еще один интересный момент: работник в штате выполняет работу, но закоммитить его на результат практически невозможно. Да, можно ввести КПИ и выгнать человека в случае невыполнения. Только зарплату ему заплатить все равно придется, причем наверняка КПИ это где-то полгода работы до первого измеримого результата (а если человек удачно отмажется, то можно и год результатов не получать, но платить зарплату).
В случае договора с юрмордой все проще: нет результатов — нет бабла. Ну, да, нет и результатов, но хотя бы деньги не потратили.
Ожидаемые же результаты же в случае договора внедрения всегда заранее известны. Прописывать ПИМИ и закрывать работы актами не вчера придумали же.
В общем, я с восхищением смотрю на компании, которые пишут сами под себя аналоги готовых продуктов, но категорически не хочу поддерживать это безумие.
То есть, при зарплате программистов в 60тр (те самые 0.5 млн в месяц) надо реально расстаться с почти миллионом рублей в тот же месяц чисто для обеспечения их зарплатой, ага?
Далее: на одно рабочее место надо бы отвести ну пусть жлобские пять квадратных метров офисной площади (реально, конечно, больше). Итого — 30 метров. Возьмем гуманные 15тр за метр в год, получим еще полляма в год.
Не забудем про транзакционную нагрузку на эйчар и пэйролл, не выпустим из виду обеспечение затратного подразделения офисной мебелью и вычтехникой, дополним все это пониманием, что реально на коллектив из 6 человек мы получаем работу 5.5, т.к. еще половина человеко-года это оплаченные отпуска.
И приходим к пониманию, что коллектив из шести человек реально нам стоит около 7 миллионов рублей ежегодно.
Как Вы думаете, смогу я коробку плюс кастомайз плюс саппорт купить дешевле и отнести все это на себестоимость плюс еще со всего, кроме коробки (а в ряде случаев и с нее) возместить НДС?
Я так думаю, что запросто.
Кроме того, есть еще один интересный момент: работник в штате выполняет работу, но закоммитить его на результат практически невозможно. Да, можно ввести КПИ и выгнать человека в случае невыполнения. Только зарплату ему заплатить все равно придется, причем наверняка КПИ это где-то полгода работы до первого измеримого результата (а если человек удачно отмажется, то можно и год результатов не получать, но платить зарплату).
В случае договора с юрмордой все проще: нет результатов — нет бабла. Ну, да, нет и результатов, но хотя бы деньги не потратили.
Ожидаемые же результаты же в случае договора внедрения всегда заранее известны. Прописывать ПИМИ и закрывать работы актами не вчера придумали же.
В общем, я с восхищением смотрю на компании, которые пишут сами под себя аналоги готовых продуктов, но категорически не хочу поддерживать это безумие.
Yurich,
Спасибо за конкретику. Относительно замечания по «прекрасно считатете» — надеюсь вы без иронии, так как являясь CEO и владельцем ИТ компании, я могу четко и обоснованно утверждать, что, например, в Новосибирске содержать 6 айтишников с ЗП средней по рынку — не превышает 0,5 млн в месяц со всеми налогами и прочими затратами. На самом деле 0,5 млн в месяц — это 6 млн в год, что не сильно, согласитесь, в данном контексте отличается от Вашей оценки в 7 млн (тем более вы говорите наверное про Москву, так как гуманные 15.т.р за метр аренды в год — это где в районе МКАД, наверное, но точно не НСК и другие миллионники, возможно Питер). Тем более мне странно видеть в Ваших расчетах плавный переход от «почти миллиона в месяц» к 7 млн в год. Т.е. с 12 к 7, согласитесь, странно. Хотя не исключаю, может я чего-то не до конца понял в Ваших выкладках. Не суть: с оценкой в 7 млн в год на 6 человек, я согласен.
Далее самое интересное:
Купить то сможете, как сможете купить новый автомобиль за 350 т.р. (но все почему то хотят хотя бы за 1 млн). Относительно «отнести на себестоимость», это Вы, простите, о чем? ФОТ как и многое другое — управленческие расходы, которые как и многое другое снижает базу налога на прибыль. Если вы покупаете услуги — аналогично ситуация, если вы покупаете лицензии, то в зависимости от вариантов учета, но скорее всего, они как основные средства будут амортизироваться в течении некоторого времени, что с точки зрения налога на прибыль хуже почти всегда чем списать в расходы сразу, поэтому разговор про «отнести все это на себестоимость» в данном контексте в пользу ЗП штатным сотрудникам, а судя по Вашей позиции, Вы не это хотите доказать. Про НДС да, верно, но для справедливости и простоты расчетов давайте далее считать расходы без учета НДС, т.е. говорим допустим проект — 5 млн (в уме держим 6 млн с НДС).
Теперь по существу, что можно ли организовать проект внедрения типового функционала на какой-либо платформе + небольшой кастум, значительно дешевле чем за 7 млн рублей. Все зависит естественно от масштаба компании и от числа задач. Диапазон тут велик: от сумм менее 1 млн до сотен миллионов. Выясняем размеры компании, сделаю предположение (на анализе инфы, что компания имела возможность содержать 6 программистов только под самописную СЭД,) что общий штат как минимум человек под 2000, т.е. довольно крупная структура. Сколько из них пользовались бы СЭД, зависит от бизнеса и задач, которые бы в СЭД были бы автоматизированы. Давайте возьмем какую то нижнюю оценку, но как минимум 200 конкурентных лицензий СЭД — вполне адекватно, с нашей статистикой более менее бьется. Задачи условно стандартные, немного кастума (именно кода). Такой проект в регионе вполне может стоить около 5 млн (лицензии + работы без НДС). Дешевле только коробки, которые реальные коробки, т.е. не классические платформы, и даже не 1С, а готовые решения, которые особо не предполагают кастума, о котором Вы говорите и которые имеют ограниченный потенциал развития. Сопровождение такого решения обойдется еще примерно в 1 млн в год и развитие, новый функционал — еще миллиона полтора.
В этих предпосылках, я лично бы решился на коммерческий проект, инвестировав 5 млн, время, силы, ресурсы нервы, чтобы получить opex'ы в районе 2,5 млн вместо 7 млн. Т.е. если новый проект гарантированно дал бы мне качественный результат, который я ожидаю, что в общем то вилами на воде писано, срок окупаемости составил бы примерно год в данной ситуации — очень неплохой показатель. Но если мы изначально говорим о, допустим, 400 конкурентных лицензиях, то проект может спокойно вылететь за 10 млн, с 3-4 млн на саппорт и развитие ежегодно. Вот тут можно и призадуматься, а стоит ли? Ведь текущий результат какой то есть, пусть не всех устраивает, а факт что в новом решении будет лучше?
Если же мы говорит о масштабах, существенно меньших чем 200 конкурентных лицензий — то простите, содержать под самописную СЭД 6 человек в данном случае — это не бизнес и не компания, это простите, какой то пионерлагерь с бесконечным кэшем. И верить что такое случается, ну как то опрометчиво, а тем более приводить где то пример такого «бизнеса» и делать какие-то выводы из этого.
На этот аргумент можно сказать следующее — безусловно эффективность внутреннего ИТ порой не сильно высока, но, на рынке среди интеграторов тоже очень много компаний, команд, мягко говоря сомнительной эффективности. Я бы сказал, что реально качественных намного меньше половины. Продавать то все горазды, а когда дело доходить до выполнения… Только в моей практике, примерно половина клиентов, которые внедряли СЭД, внедряли СЭД не первый раз.
Нет результатов — это как? Система не внедрена? Не удовлетворяет условиям ПМИ? Тогда верно. Только результат для заказчика обычно не в том, что система установлена и удовлетворяет ПМИ, что пользователи обучены и т.п., а в том, что цели проекта достигнуты и от использования системы есть реальная польза. Вот это результат, но ни в каком договоре с юр.лицом вы не сможете сформулировать и зафиксировать реальную количественную пользу в качестве критерия закрытия работ, этапов. Точнее даже если это удаться сделать, то дурак тот интегратор, что такой договор подписал: ведь реальная польза от внедрения СЭД достигается только при его корректном и качественном использовании и во времени (ну и естественно, при условии что внедрено качественно), и если приоритеты и задачи были выбраны адекватно потребностям бизнеса — а это практически никогда не бывает в компетенции исполнителя.
Поверьте, если Вам встречались только неудачные примеры самописных систем, то означает ровно то, что тем кого Вы видели, не повезло. Примеров качесвтенных самописных систем — море, компании их содержащии обычно отдают себе отчет, что в целом содержать такую систему вероятно дороже, но множество факторов говорит в пользу текущего решения. Постепенно с развитием платформ и продуктов на рынке, естественно ценность самописных решений падает, это очевидно. Пропадет ли совсем со временем — не уверен. Я не фанат «самописного подхода», мне наоборот это невыгодно — моя деятельность — внедрение систем на базе платформ высокой степени прикладной готовности. Но это не отменает того факта, что проект создания системы, той же СЭД с нуля — может быть оправдан, успешен и выгоден и такие примеры есть.
Спасибо за конкретику. Относительно замечания по «прекрасно считатете» — надеюсь вы без иронии, так как являясь CEO и владельцем ИТ компании, я могу четко и обоснованно утверждать, что, например, в Новосибирске содержать 6 айтишников с ЗП средней по рынку — не превышает 0,5 млн в месяц со всеми налогами и прочими затратами. На самом деле 0,5 млн в месяц — это 6 млн в год, что не сильно, согласитесь, в данном контексте отличается от Вашей оценки в 7 млн (тем более вы говорите наверное про Москву, так как гуманные 15.т.р за метр аренды в год — это где в районе МКАД, наверное, но точно не НСК и другие миллионники, возможно Питер). Тем более мне странно видеть в Ваших расчетах плавный переход от «почти миллиона в месяц» к 7 млн в год. Т.е. с 12 к 7, согласитесь, странно. Хотя не исключаю, может я чего-то не до конца понял в Ваших выкладках. Не суть: с оценкой в 7 млн в год на 6 человек, я согласен.
Далее самое интересное:
Как Вы думаете, смогу я коробку плюс кастомайз плюс саппорт купить дешевле и отнести все это на себестоимость плюс еще со всего, кроме коробки (а в ряде случаев и с нее) возместить НДС?
Купить то сможете, как сможете купить новый автомобиль за 350 т.р. (но все почему то хотят хотя бы за 1 млн). Относительно «отнести на себестоимость», это Вы, простите, о чем? ФОТ как и многое другое — управленческие расходы, которые как и многое другое снижает базу налога на прибыль. Если вы покупаете услуги — аналогично ситуация, если вы покупаете лицензии, то в зависимости от вариантов учета, но скорее всего, они как основные средства будут амортизироваться в течении некоторого времени, что с точки зрения налога на прибыль хуже почти всегда чем списать в расходы сразу, поэтому разговор про «отнести все это на себестоимость» в данном контексте в пользу ЗП штатным сотрудникам, а судя по Вашей позиции, Вы не это хотите доказать. Про НДС да, верно, но для справедливости и простоты расчетов давайте далее считать расходы без учета НДС, т.е. говорим допустим проект — 5 млн (в уме держим 6 млн с НДС).
Теперь по существу, что можно ли организовать проект внедрения типового функционала на какой-либо платформе + небольшой кастум, значительно дешевле чем за 7 млн рублей. Все зависит естественно от масштаба компании и от числа задач. Диапазон тут велик: от сумм менее 1 млн до сотен миллионов. Выясняем размеры компании, сделаю предположение (на анализе инфы, что компания имела возможность содержать 6 программистов только под самописную СЭД,) что общий штат как минимум человек под 2000, т.е. довольно крупная структура. Сколько из них пользовались бы СЭД, зависит от бизнеса и задач, которые бы в СЭД были бы автоматизированы. Давайте возьмем какую то нижнюю оценку, но как минимум 200 конкурентных лицензий СЭД — вполне адекватно, с нашей статистикой более менее бьется. Задачи условно стандартные, немного кастума (именно кода). Такой проект в регионе вполне может стоить около 5 млн (лицензии + работы без НДС). Дешевле только коробки, которые реальные коробки, т.е. не классические платформы, и даже не 1С, а готовые решения, которые особо не предполагают кастума, о котором Вы говорите и которые имеют ограниченный потенциал развития. Сопровождение такого решения обойдется еще примерно в 1 млн в год и развитие, новый функционал — еще миллиона полтора.
В этих предпосылках, я лично бы решился на коммерческий проект, инвестировав 5 млн, время, силы, ресурсы нервы, чтобы получить opex'ы в районе 2,5 млн вместо 7 млн. Т.е. если новый проект гарантированно дал бы мне качественный результат, который я ожидаю, что в общем то вилами на воде писано, срок окупаемости составил бы примерно год в данной ситуации — очень неплохой показатель. Но если мы изначально говорим о, допустим, 400 конкурентных лицензиях, то проект может спокойно вылететь за 10 млн, с 3-4 млн на саппорт и развитие ежегодно. Вот тут можно и призадуматься, а стоит ли? Ведь текущий результат какой то есть, пусть не всех устраивает, а факт что в новом решении будет лучше?
Если же мы говорит о масштабах, существенно меньших чем 200 конкурентных лицензий — то простите, содержать под самописную СЭД 6 человек в данном случае — это не бизнес и не компания, это простите, какой то пионерлагерь с бесконечным кэшем. И верить что такое случается, ну как то опрометчиво, а тем более приводить где то пример такого «бизнеса» и делать какие-то выводы из этого.
Кроме того, есть еще один интересный момент: работник в штате выполняет работу, но закоммитить его на результат практически невозможно. Да, можно ввести КПИ и выгнать человека в случае невыполнения. Только зарплату ему заплатить все равно придется, причем наверняка КПИ это где-то полгода работы до первого измеримого результата (а если человек удачно отмажется, то можно и год результатов не получать, но платить зарплату).
На этот аргумент можно сказать следующее — безусловно эффективность внутреннего ИТ порой не сильно высока, но, на рынке среди интеграторов тоже очень много компаний, команд, мягко говоря сомнительной эффективности. Я бы сказал, что реально качественных намного меньше половины. Продавать то все горазды, а когда дело доходить до выполнения… Только в моей практике, примерно половина клиентов, которые внедряли СЭД, внедряли СЭД не первый раз.
В случае договора с юрмордой все проще: нет результатов — нет бабла. Ну, да, нет и результатов, но хотя бы деньги не потратили.
Ожидаемые же результаты же в случае договора внедрения всегда заранее известны. Прописывать ПИМИ и закрывать работы актами не вчера придумали же.
Нет результатов — это как? Система не внедрена? Не удовлетворяет условиям ПМИ? Тогда верно. Только результат для заказчика обычно не в том, что система установлена и удовлетворяет ПМИ, что пользователи обучены и т.п., а в том, что цели проекта достигнуты и от использования системы есть реальная польза. Вот это результат, но ни в каком договоре с юр.лицом вы не сможете сформулировать и зафиксировать реальную количественную пользу в качестве критерия закрытия работ, этапов. Точнее даже если это удаться сделать, то дурак тот интегратор, что такой договор подписал: ведь реальная польза от внедрения СЭД достигается только при его корректном и качественном использовании и во времени (ну и естественно, при условии что внедрено качественно), и если приоритеты и задачи были выбраны адекватно потребностям бизнеса — а это практически никогда не бывает в компетенции исполнителя.
В общем, я с восхищением смотрю на компании, которые пишут сами под себя аналоги готовых продуктов, но категорически не хочу поддерживать это безумие.
Поверьте, если Вам встречались только неудачные примеры самописных систем, то означает ровно то, что тем кого Вы видели, не повезло. Примеров качесвтенных самописных систем — море, компании их содержащии обычно отдают себе отчет, что в целом содержать такую систему вероятно дороже, но множество факторов говорит в пользу текущего решения. Постепенно с развитием платформ и продуктов на рынке, естественно ценность самописных решений падает, это очевидно. Пропадет ли совсем со временем — не уверен. Я не фанат «самописного подхода», мне наоборот это невыгодно — моя деятельность — внедрение систем на базе платформ высокой степени прикладной готовности. Но это не отменает того факта, что проект создания системы, той же СЭД с нуля — может быть оправдан, успешен и выгоден и такие примеры есть.
Yurich, lair,
С точки зрения состава «противопоказаний» вероятно ничего из вышесказанного не специфично именно для СЭД и перечень наверняка не полон. Специфичность для СЭД можно и следует искать в деталях, в особенностях влияния того или иного фактора именно в этой сфере. Тогда придется отвечать на вопрос: а чем вообще проект внедрения, или в целом специфика СЭД отличается от всех других, допустим от CRM и ERP. Однозначного ответа наверняка на такой, достаточно фундаментальный вопрос, вероятно нет. Со своей «колокольни» мог бы отметить, что в целом процессы, относящиеся к ECM, менее формализованы и упорядочены на практике. Это на самом деле очевидно, ввиду того что «ECM-процессы» как правило с точки зрения основного бизнеса на периферии: мало кто будет спорить что тех. процесс по изготовлению изделия вероятно в конкретной ситуации важнее чем процесс, утрирую, работы с входящей корреспонденцией. Насколько важен процесс бюджетирования, финансового планирования, продаж, относительно скажем процессов работы с ОРД. И с развитием бизнеса прикладным процессам естественно уделяется повышенное внимание. При выборе направлений развития лицо, принимающее решение, с большей вероятностью выберет курс на «реальный сектор» (производственный, финансовый и т.п.) и в этом вероятно глубочайшее заблуждение, так как например, такая сфера, как исполнительская дисциплина и ее контроль, с точки зрения управления, а значит и бизнес в целом, задача первостепенная. С учетом уклона в развитии на предметный, отраслевой сектор, фундаментальные вопросы управления, в т.ч. попытки какой то автоматизации управления, на практике зачастую откладываются «на будущее», позволяя компании как организму все больше и больше «привыкать» к отсутствию понятных и эффективных правил в этом направлении.
С учетом, сказанного, а именно «пониженной» формализации процессов ECM (банально с ходу менее понятно, что же с ними делать), такое противопоказание, как например, «нет ответственного» начинают иметь более острое влияние: насколько компетентен и эффективен будет выбранный ответственный, по сравнению с ответственными для CRM (тут то условно все понятно — ком.дира берем в оборот и все ок). Или «пациент не хочет лечится» к контексте СЭД более острое противопоказание, нежели в ERP (банально практика 3-лет в ERP и 5-ти летняя в ECM позволяет это утверждать, насколько по разному возмущаются пользователи при том и при другом, ну там и охват другой). Поэтому стоит, на мой взгляд, учитывать не состав как таковой, а различность влияния и важности в зависимости от класса систем.
С точки зрения состава «противопоказаний» вероятно ничего из вышесказанного не специфично именно для СЭД и перечень наверняка не полон. Специфичность для СЭД можно и следует искать в деталях, в особенностях влияния того или иного фактора именно в этой сфере. Тогда придется отвечать на вопрос: а чем вообще проект внедрения, или в целом специфика СЭД отличается от всех других, допустим от CRM и ERP. Однозначного ответа наверняка на такой, достаточно фундаментальный вопрос, вероятно нет. Со своей «колокольни» мог бы отметить, что в целом процессы, относящиеся к ECM, менее формализованы и упорядочены на практике. Это на самом деле очевидно, ввиду того что «ECM-процессы» как правило с точки зрения основного бизнеса на периферии: мало кто будет спорить что тех. процесс по изготовлению изделия вероятно в конкретной ситуации важнее чем процесс, утрирую, работы с входящей корреспонденцией. Насколько важен процесс бюджетирования, финансового планирования, продаж, относительно скажем процессов работы с ОРД. И с развитием бизнеса прикладным процессам естественно уделяется повышенное внимание. При выборе направлений развития лицо, принимающее решение, с большей вероятностью выберет курс на «реальный сектор» (производственный, финансовый и т.п.) и в этом вероятно глубочайшее заблуждение, так как например, такая сфера, как исполнительская дисциплина и ее контроль, с точки зрения управления, а значит и бизнес в целом, задача первостепенная. С учетом уклона в развитии на предметный, отраслевой сектор, фундаментальные вопросы управления, в т.ч. попытки какой то автоматизации управления, на практике зачастую откладываются «на будущее», позволяя компании как организму все больше и больше «привыкать» к отсутствию понятных и эффективных правил в этом направлении.
С учетом, сказанного, а именно «пониженной» формализации процессов ECM (банально с ходу менее понятно, что же с ними делать), такое противопоказание, как например, «нет ответственного» начинают иметь более острое влияние: насколько компетентен и эффективен будет выбранный ответственный, по сравнению с ответственными для CRM (тут то условно все понятно — ком.дира берем в оборот и все ок). Или «пациент не хочет лечится» к контексте СЭД более острое противопоказание, нежели в ERP (банально практика 3-лет в ERP и 5-ти летняя в ECM позволяет это утверждать, насколько по разному возмущаются пользователи при том и при другом, ну там и охват другой). Поэтому стоит, на мой взгляд, учитывать не состав как таковой, а различность влияния и важности в зависимости от класса систем.
Главное в статье — подпись
Начинать автоматизацию нужно с выявления «узких мест», проблемных областей автоматизируемых процессов, например...
Правильно ли я понимаю, что речь идет о сборе требований и обследовании процессов заказчика? Если да, то такие есть рекомендации, методики вы используете? Есть ли что-то специфичное для СЭД или все как по Вигерсу?
staskin1, благодарю за интересный вопрос!
Отчасти, да — сбор требований, обследование и т.д. Но, задумайтесь, почему, вроде бы, все делают «по учебнику», но не каждый проект проходит гладко? Важно, КАК и КАКИЕ вопросы в этом обследовании задавать и КАКИЕ отношения уже выстроены с Заказчиком (доверительные, диалог профессионалов, на уровне «я-ок — ты-ок»). Успех в том, что вопросы надо задавать откровенные, где-то неудобные, да, Заказчику не всегда приятно говорить о тех областях, где неладно, где болит, где беспорядок. Но важно пройти с ним вместе этот этап. Иначе самая суть будет скрыта за пеленой «водных» целей вида «повысить эффективность», «снизить издержки». Все это не имеет смысла пока цели не прописаны до деталей. Например, достижение экономического эффекта от внедрения системы путем включения показателей исполнительской дисциплины в систему мотивацию каждого сотрудника. М, чувствуется разница? Вот из воды и надо выводить Заказчика на сушу. Методология вся хороша. Важно, как вы ее исполняете. Удачи!
Отчасти, да — сбор требований, обследование и т.д. Но, задумайтесь, почему, вроде бы, все делают «по учебнику», но не каждый проект проходит гладко? Важно, КАК и КАКИЕ вопросы в этом обследовании задавать и КАКИЕ отношения уже выстроены с Заказчиком (доверительные, диалог профессионалов, на уровне «я-ок — ты-ок»). Успех в том, что вопросы надо задавать откровенные, где-то неудобные, да, Заказчику не всегда приятно говорить о тех областях, где неладно, где болит, где беспорядок. Но важно пройти с ним вместе этот этап. Иначе самая суть будет скрыта за пеленой «водных» целей вида «повысить эффективность», «снизить издержки». Все это не имеет смысла пока цели не прописаны до деталей. Например, достижение экономического эффекта от внедрения системы путем включения показателей исполнительской дисциплины в систему мотивацию каждого сотрудника. М, чувствуется разница? Вот из воды и надо выводить Заказчика на сушу. Методология вся хороша. Важно, как вы ее исполняете. Удачи!
Ладно, спрошу еще прямее. Даете ли вы потенциальному заказчику какой-либо «шаблон» для сбора и формализации требований?
В моей практике, «шаблоны» в СЭД проекте в этом контексте как таковые слабо-эффективны. Они в итоге получаются либо слишком общего характера, что в целях сбора требований не несет никакой пользы для собирающих, либо если детализированные не учитывают конкретную ситуацию, а это часто вводит отвечающего в ступор, он либо не дает ответа на часть таких вопросов, либо отвечает «как то непонятно» :). По факту некий инструмент анкетирования используется, но в каждом новом проекте «анкета» очень сильно перерабатывается каждый раз исходя из первоначального общения о целях, задачах, границах, предпосылках, особенностях компании и т.п.
Это не список противопоказаний, это список заблуждений и косяков исполнителя…
1) Неправильная диагностика — это проблема исполнителя, а не заказчика.
2) Представления о СЭД как об антибиотике — это проблема исполнителя. Он неправильно информирует заказчика о реальном эффекте от внедрения системы. Зачастую это происходит злонамеренно. Это главная причина дурной славы СЭД.
3) «Пациент» не хочет «лечиться» — в коллективе всегда есть люди, которые будут противиться внедрению системы. Как не странно чаще всего главный противник это те, кто на момент внедрения занимается документооборотом. Причины этого — совершенно конкретные, но это отдельная большая тема…
4) Нет ответственного — это, как правило, прямое следствие предыдущего пункта.
5) Бюджет «лечения» неадекватен потребности — это проблема имеет то же происхождение, что и проблема во 2 пункте… Редкий исполнитель решиться информировать клиента о реальных расходах на содержание системы документооборота на предприятии. Надо ли объяснять почему?
6) Сочетаемость «препаратов» — это проблема тоже должна решаться корректной диагностикой (п.1).
7) Несоответствие «лечения» масштабам «заболевания» — это до кучи к предыдущему пункту…
1) Неправильная диагностика — это проблема исполнителя, а не заказчика.
2) Представления о СЭД как об антибиотике — это проблема исполнителя. Он неправильно информирует заказчика о реальном эффекте от внедрения системы. Зачастую это происходит злонамеренно. Это главная причина дурной славы СЭД.
3) «Пациент» не хочет «лечиться» — в коллективе всегда есть люди, которые будут противиться внедрению системы. Как не странно чаще всего главный противник это те, кто на момент внедрения занимается документооборотом. Причины этого — совершенно конкретные, но это отдельная большая тема…
4) Нет ответственного — это, как правило, прямое следствие предыдущего пункта.
5) Бюджет «лечения» неадекватен потребности — это проблема имеет то же происхождение, что и проблема во 2 пункте… Редкий исполнитель решиться информировать клиента о реальных расходах на содержание системы документооборота на предприятии. Надо ли объяснять почему?
6) Сочетаемость «препаратов» — это проблема тоже должна решаться корректной диагностикой (п.1).
7) Несоответствие «лечения» масштабам «заболевания» — это до кучи к предыдущему пункту…
northbear, да, как и Вы, не хотела бы встретиться с таким исполнителем!) Вы правы в том, что от Исполнителя тоже много зависит. а я бы расширила горизонт: процесс выбора и внедрения — вещь обоюдная, все как в семье, счастье зависит от вклада обеих сторон. Дай Бог всем добросовестных Исполнителей, которые «слабости» Заказчика превращаюст в ходе проекта «в силу», которые поддерживают и строят крепкие отношения! Обращайтесь, если что, мы разделяем эти ценности!))
Из всего написанного на этой странице я хотел бы уточнить у автора статьи насчет пункта «Нет ответственного». В целом у задачи «управление контентом предприятия» не может быть одного ответственного. Как решаете это вы? Как вообще можно выносить этот пункт в перечень противопоказаний к внедрению?
Yakimchuk, «нет ответственного» стоит понимать как «отсутствие назначенного сотрудника (группы сотрудников)… ». Заказчик может быть представлен как в едином лице (глава канцелярии, СМК или департамента развития, а в небольших компаниях — это руководитель предприятия, ДИТ в связке с директором), так и может быть представлен группой ответственных, имеющих четкие границы разделения полномочий по процессам. В случае «составного» Заказчика необходим такой орган управления проектом со стороны клиента как Управляющий комитет, привлекаемый для принятия стратегических решений по проекту, а также в случаях принятия решений об изменении бюджета/функциональных или календарных границ.
Отсутствие Заказчика может привести гарантированно к задержке сроков согласования и утверждения результата проекта, не возможности принятия решений в ходе спорных ситуаций внутри рабочей группы, а, самое главное, отсутствие примера и авторитета в ходе внедрения. А это значит, неуспешность проекта почти гарантированна. Предупредить об этом клиента, на мой взгляд, профессионально важно и этично.
Отсутствие Заказчика может привести гарантированно к задержке сроков согласования и утверждения результата проекта, не возможности принятия решений в ходе спорных ситуаций внутри рабочей группы, а, самое главное, отсутствие примера и авторитета в ходе внедрения. А это значит, неуспешность проекта почти гарантированна. Предупредить об этом клиента, на мой взгляд, профессионально важно и этично.
northbear
Это взаимная ответственность: очень часть заказчик не в состоянии адекватно выделить ключевые свои потребности и их значение и влияние, соответственно вводит и себя и всех в заблуждение относительно своих реальных приоритетов. На возможный контраргумент, о том, что качественный исполнитель проведет такой анализ что сам выявит сходу реальные потребности в полном объеме — скажу, что да, верно, только стоить такие работы будут солидно, а у нас в стране к сожалению не привыкли платить много за анализ и консалтинг.
Верно то что зачастую и злонамеренно вводят в заблуждение при продаже в основном. Но в описании этого пункта — речь то не об этом. А о том, что у Заказчика изначально зачастую ожидания вида «вот сейчас куплю, денег вкину, и мне все за меня сделают». Эти убеждения естественно надо разрушать
Так о том и речь — необходимо организовать процесс таким образом, чтобы минимизировать саботаж. Почему Вы называете это утверждение заблуждением или чьим то «косяком»?
На самом деле это следствие, простите за банальность, «незрелости» компании в вопросах внедрения крупных проектов.
Понятно, что многие на рынке избегают разговоров о реальных будущих тратах. Очевидно почему. Но в пункте смысл — предупреждение. Там как раз намек, что все не так просто, и потребуется дальнейшие вложения, иногда довольно таки внушительные. Это надо понимать. В чем же заблуждения?
1) Неправильная диагностика — это проблема исполнителя, а не заказчика.
Это взаимная ответственность: очень часть заказчик не в состоянии адекватно выделить ключевые свои потребности и их значение и влияние, соответственно вводит и себя и всех в заблуждение относительно своих реальных приоритетов. На возможный контраргумент, о том, что качественный исполнитель проведет такой анализ что сам выявит сходу реальные потребности в полном объеме — скажу, что да, верно, только стоить такие работы будут солидно, а у нас в стране к сожалению не привыкли платить много за анализ и консалтинг.
2) Представления о СЭД как об антибиотике — это проблема исполнителя. Он неправильно информирует заказчика о реальном эффекте от внедрения системы. Зачастую это происходит злонамеренно. Это главная причина дурной славы СЭД.
Верно то что зачастую и злонамеренно вводят в заблуждение при продаже в основном. Но в описании этого пункта — речь то не об этом. А о том, что у Заказчика изначально зачастую ожидания вида «вот сейчас куплю, денег вкину, и мне все за меня сделают». Эти убеждения естественно надо разрушать
3) «Пациент» не хочет «лечиться» — в коллективе всегда есть люди, которые будут противиться внедрению системы. Как не странно чаще всего главный противник это те, кто на момент внедрения занимается документооборотом. Причины этого — совершенно конкретные, но это отдельная большая тема…
Так о том и речь — необходимо организовать процесс таким образом, чтобы минимизировать саботаж. Почему Вы называете это утверждение заблуждением или чьим то «косяком»?
4) Нет ответственного — это, как правило, прямое следствие предыдущего пункта.
На самом деле это следствие, простите за банальность, «незрелости» компании в вопросах внедрения крупных проектов.
5) Бюджет «лечения» неадекватен потребности — это проблема имеет то же происхождение, что и проблема во 2 пункте… Редкий исполнитель решиться информировать клиента о реальных расходах на содержание системы документооборота на предприятии. Надо ли объяснять почему?
Понятно, что многие на рынке избегают разговоров о реальных будущих тратах. Очевидно почему. Но в пункте смысл — предупреждение. Там как раз намек, что все не так просто, и потребуется дальнейшие вложения, иногда довольно таки внушительные. Это надо понимать. В чем же заблуждения?
Взаимная ответственность — это хорошо. Возложить хоть какую-то часть ответственности за свою работу на заказчика это мечта любого исполнителя. Но… Лично я почти не сталкивался с заказчиками, которые заказывают СЭД только для того, чтобы «было». Как правило, на момент обращения заказчика у него есть уже вполне конкретная острая проблема с документооборотом, которую он хочет решить внедрив СЭД… Но это когда нормальные заказчики.
Когда СЭД заказывают в какой-нибудь госструктуре или госкорпорации для отмыва денег, вот тогда да, всё становится плохо. Тут как правило изначальная система работает и так, все справляются, но появляются какие-то ребята, которые начинают им рассказывать, что им тут нужно всё поменять.
При этом все знают, что эти ребята получили за это какую-то нереальную сумму и тем не менее эти ребята пытаются выполнить свои обязанности силами рядовых работников Заказчика. И на аргументы работников компании, начальство дает команду выполнять все распоряжения этих ребят бесприкословно…
Вот тогда и получается всё в точности так, как описано в статье…
Когда СЭД заказывают в какой-нибудь госструктуре или госкорпорации для отмыва денег, вот тогда да, всё становится плохо. Тут как правило изначальная система работает и так, все справляются, но появляются какие-то ребята, которые начинают им рассказывать, что им тут нужно всё поменять.
При этом все знают, что эти ребята получили за это какую-то нереальную сумму и тем не менее эти ребята пытаются выполнить свои обязанности силами рядовых работников Заказчика. И на аргументы работников компании, начальство дает команду выполнять все распоряжения этих ребят бесприкословно…
Вот тогда и получается всё в точности так, как описано в статье…
А о том, что у Заказчика изначально зачастую ожидания вида «вот сейчас куплю, денег вкину, и мне все за меня сделают».Давайте еще раз: Откуда у заказчика такие заблуждения? Вы например, когда машину покупаете, это не значит что раз вы деньги заплатили и теперь она сама должна ехать куда вы захотите? Всем ведь понятно, что машиной надо учиться управлять, нужно знать правила дорожного движения и еще кучу всего… Так почему в данном случае заказчик вдруг считает, сто всё должно заработать само по себе? 0_о Мой пардон, конечно, но это лукавство…
На самом деле это следствие, простите за банальность, «незрелости» компании в вопросах внедрения крупных проектов.Вы какую компанию имеете ввиду компанию-заказчика или компанию-исполнителя? Давайте тогда для начала договоримся о понятиях. Что значит «нет ответственного»? Формально назначенный ответственный, не выполняющий свои обязанности, это «нет ответственного» или есть?
Игорь, то что на момент обращения у заказчика есть конкретная проблематика не говорит о том что в общем виде он правильно понимает причины этих проблем и делает соответствующие выводы. Например, проблематика заказчика — «у меня долго, по три недели, согласуются договора на продажу, до момента сделки проходит много времени, мы позже получаем деньги от продаж, в общем сплошные издержки — СЭД нам поможет». Вроде все логично, есть проблематика, есть обоснование, только когда дело доходит до причин — вот тут, пиши пропало. А в данном примере банально 2 из 3 недель договор висел в СБ которые просто так долго работают, и без визы которого секретарь не несет согласно внутреннему регламенту документ на подпись. Думаете никто в компании не знал, что договора висят постоянно в СБ? Помогла ли бы тут СЭД? Чем? Заставила бы СБ работать быстрее? или убедила руководство в том, что нет необходимости в такой тщательной проверке контрагентов при продаже (а не при покупке)? Утрированный пример, который не характеризует заказчика, как нормального, безусловно. Но он просто яркий и показательный. А менее ярких примеров — уйма, и у вполне нормальных заказчиков. Порой удивительно, насколько много «багов» в организационных вопросах у крупного предприятия. Что в данной ситуации делать? Ответ то очевиден — независимая диагностика, предпроектное обследование, на самом деле без ИТ уклона, именно предметная область. Вы представляете масштаб таких работ, чтобы еще было приемлемое качество? Как Вы думаете, насколько велика вероятность продать такое, если у Вас на рынке туча предложений вида «внедрим СЭД под ключ за 100 т.р.»? Мы все хотим работать и жить в идеальных условиях, а приходится жить в реальных. Когда говорим про взаимную ответственность в данном контексте — это означает либо полную готовность заказчика адекватно оценить ситуацию, в которой он находится в интересующем нас контексте, и нести ответственность за достоверность такой информации, либо финансировать эти исследования перед тем, как вообще вести разговор о границах, стоимости проекта по внедрению СЭД. Последнее на практике редкость.
Относительно госструктур и госкорпораций — не берусь судить, только раз был опыт, больше не хочется, поэтому скорее соглашусь с Вами в этом вопросе.
А потому что пример с автомобилем хоть и красив, но не контраргумент ни разу. :) Покупая машину, я сужу по себе, я ожидаю что она будет адекватно ездить, управляться, и много чего еще. Вы доводите до абсурда, сравнивая эти вещи. А причина исходного ожидания в том, что у нас такой рынок, такова жизнь, увы. Человеку проще все свалить на других с фразой «вы же профессионалы», нежели расписать в своей неспособности поставить четко задачу и организовать свою часть процесса внедрения на своей стороне. И как ни крутите, вы будете вынуждены с этим работать и бесплатно ставить заказчику процесс по внедрению внутренних ИТ-проектов. А потом еще и нести за это ответственность. Бывают исключения и действительно «зрелые» заказчики с поставленными процессами. Но у них давно уже все внедрено :), а если серьезно, то просто очень редко в процентном соотношении.
Конечно, заказчика)
Давайте лучше не заниматься игрой слов. Я думаю очевидно, что формально назначенный ответственный, не исполняющий своих обязанностей, все равно что «нет ответственного». А также Вы наверняка себе отдаете отчет, что ситуации когда ответственного нет даже формально, это какая то дикость и, мягко говоря, маловероятна. Формально назначить формального ответственного и потом формально с него попросить формально ответить за формальный результат, ведь это же не проблема? )
Относительно госструктур и госкорпораций — не берусь судить, только раз был опыт, больше не хочется, поэтому скорее соглашусь с Вами в этом вопросе.
Так почему в данном случае заказчик вдруг считает, сто всё должно заработать само по себе?
А потому что пример с автомобилем хоть и красив, но не контраргумент ни разу. :) Покупая машину, я сужу по себе, я ожидаю что она будет адекватно ездить, управляться, и много чего еще. Вы доводите до абсурда, сравнивая эти вещи. А причина исходного ожидания в том, что у нас такой рынок, такова жизнь, увы. Человеку проще все свалить на других с фразой «вы же профессионалы», нежели расписать в своей неспособности поставить четко задачу и организовать свою часть процесса внедрения на своей стороне. И как ни крутите, вы будете вынуждены с этим работать и бесплатно ставить заказчику процесс по внедрению внутренних ИТ-проектов. А потом еще и нести за это ответственность. Бывают исключения и действительно «зрелые» заказчики с поставленными процессами. Но у них давно уже все внедрено :), а если серьезно, то просто очень редко в процентном соотношении.
Вы какую компанию имеете ввиду компанию-заказчика или компанию-исполнителя?
Конечно, заказчика)
Давайте тогда для начала договоримся о понятиях. Что значит «нет ответственного»? Формально назначенный ответственный, не выполняющий свои обязанности, это «нет ответственного» или есть?
Давайте лучше не заниматься игрой слов. Я думаю очевидно, что формально назначенный ответственный, не исполняющий своих обязанностей, все равно что «нет ответственного». А также Вы наверняка себе отдаете отчет, что ситуации когда ответственного нет даже формально, это какая то дикость и, мягко говоря, маловероятна. Формально назначить формального ответственного и потом формально с него попросить формально ответить за формальный результат, ведь это же не проблема? )
Реальным противопоказаниями к внедрению СЭД являются действующее законодательство, регламенты и НПА… Приведение их в соответствие с современными технологиями как правило находится за пределами компетенции Исполнителя…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
СЭД: имеются противопоказания