Помимо отсутствия судебной практики относительно электронной подписи, а также положений регламентирующих обязательное бумажное хранение и обращения некоторых видов документов, что-то имеется ввиду, или только то что я перечислил?
Игорь, то что на момент обращения у заказчика есть конкретная проблематика не говорит о том что в общем виде он правильно понимает причины этих проблем и делает соответствующие выводы. Например, проблематика заказчика — «у меня долго, по три недели, согласуются договора на продажу, до момента сделки проходит много времени, мы позже получаем деньги от продаж, в общем сплошные издержки — СЭД нам поможет». Вроде все логично, есть проблематика, есть обоснование, только когда дело доходит до причин — вот тут, пиши пропало. А в данном примере банально 2 из 3 недель договор висел в СБ которые просто так долго работают, и без визы которого секретарь не несет согласно внутреннему регламенту документ на подпись. Думаете никто в компании не знал, что договора висят постоянно в СБ? Помогла ли бы тут СЭД? Чем? Заставила бы СБ работать быстрее? или убедила руководство в том, что нет необходимости в такой тщательной проверке контрагентов при продаже (а не при покупке)? Утрированный пример, который не характеризует заказчика, как нормального, безусловно. Но он просто яркий и показательный. А менее ярких примеров — уйма, и у вполне нормальных заказчиков. Порой удивительно, насколько много «багов» в организационных вопросах у крупного предприятия. Что в данной ситуации делать? Ответ то очевиден — независимая диагностика, предпроектное обследование, на самом деле без ИТ уклона, именно предметная область. Вы представляете масштаб таких работ, чтобы еще было приемлемое качество? Как Вы думаете, насколько велика вероятность продать такое, если у Вас на рынке туча предложений вида «внедрим СЭД под ключ за 100 т.р.»? Мы все хотим работать и жить в идеальных условиях, а приходится жить в реальных. Когда говорим про взаимную ответственность в данном контексте — это означает либо полную готовность заказчика адекватно оценить ситуацию, в которой он находится в интересующем нас контексте, и нести ответственность за достоверность такой информации, либо финансировать эти исследования перед тем, как вообще вести разговор о границах, стоимости проекта по внедрению СЭД. Последнее на практике редкость.
Относительно госструктур и госкорпораций — не берусь судить, только раз был опыт, больше не хочется, поэтому скорее соглашусь с Вами в этом вопросе.
Так почему в данном случае заказчик вдруг считает, сто всё должно заработать само по себе?
А потому что пример с автомобилем хоть и красив, но не контраргумент ни разу. :) Покупая машину, я сужу по себе, я ожидаю что она будет адекватно ездить, управляться, и много чего еще. Вы доводите до абсурда, сравнивая эти вещи. А причина исходного ожидания в том, что у нас такой рынок, такова жизнь, увы. Человеку проще все свалить на других с фразой «вы же профессионалы», нежели расписать в своей неспособности поставить четко задачу и организовать свою часть процесса внедрения на своей стороне. И как ни крутите, вы будете вынуждены с этим работать и бесплатно ставить заказчику процесс по внедрению внутренних ИТ-проектов. А потом еще и нести за это ответственность. Бывают исключения и действительно «зрелые» заказчики с поставленными процессами. Но у них давно уже все внедрено :), а если серьезно, то просто очень редко в процентном соотношении.
Вы какую компанию имеете ввиду компанию-заказчика или компанию-исполнителя?
Конечно, заказчика)
Давайте тогда для начала договоримся о понятиях. Что значит «нет ответственного»? Формально назначенный ответственный, не выполняющий свои обязанности, это «нет ответственного» или есть?
Давайте лучше не заниматься игрой слов. Я думаю очевидно, что формально назначенный ответственный, не исполняющий своих обязанностей, все равно что «нет ответственного». А также Вы наверняка себе отдаете отчет, что ситуации когда ответственного нет даже формально, это какая то дикость и, мягко говоря, маловероятна. Формально назначить формального ответственного и потом формально с него попросить формально ответить за формальный результат, ведь это же не проблема? )
Сложно оценивать необходимость такого разнообразия и деления в общем случае. По умолчанию, это вызывает скепсис, что естественно, с учетом конкретного опыта — все таки самый крупный мой проект был масштаба порядка 15000 человеко-часов, 1,5 года. Много это или не очень, не мне судить, но мне хватило :)
И даже в этом проекте не было очевидной необходимости разделять разные «аналитические» роли между разными людьми, одного ресурса с точки зрения экономической целесообразности было достаточно, это было по силам. Понятно, что в таком случае вынужденная замена такой роли в таком проекте — смерти подобно, но не вижу, насколько сильно бы ситуацию спасло подобное деление. Естественно риски меньше, но, имхо, не значительно, относительно гораздо больших накладных и издержек взаимодействия.
Но не спорю, что при более плотном изучении процесса в компании с потоком действительно крупных проектов, не изменил бы своего мнения.
Спасибо за комментарий.
Станислав,
за ссылочку огромное спасибо! Относительно профстандарта (октябрь 2014?, совсем недавно?) — безусловно часть вопросов снимает, остается только жалеть, что размещать в вакансиях такой перечень — бесперспективно, так как вряд ли кто то откликнется на такой серьезный перечень не запросив за это баснословную сумму :). В регионах это особенно актуально. С точки зрения систематизации требований и понимания подхода к возможному выращиванию — незаменимо. И сам ресурс школы, спасибо за то, что познакомили. Это для меня открытие, что такое в принципе существовало.
На самом деле давно был знаком с разделением понятий и ролей на бизнес-аналитика и системного аналитика. Вся проблема в том, что в существующих рыночных условия бить таким образом эти роли, формируя в команде под эти цели как минимум двух разных людей, учитывая проблемы утилизации и прочие накладны, это грозит поставить под сомнения экономическую эффективность такой модели. Если проект не имеет каких то запредельных масштабов, а особенно если из раза в раз проекты в одной и той же предметной плоскости, имхо, это должен быть всегда один человек в двух ролях. Либо часть роли системного аналитика должна ложится на архитектора.
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 человек в данном случае — это не бизнес и не компания, это простите, какой то пионерлагерь с бесконечным кэшем. И верить что такое случается, ну как то опрометчиво, а тем более приводить где то пример такого «бизнеса» и делать какие-то выводы из этого.
Кроме того, есть еще один интересный момент: работник в штате выполняет работу, но закоммитить его на результат практически невозможно. Да, можно ввести КПИ и выгнать человека в случае невыполнения. Только зарплату ему заплатить все равно придется, причем наверняка КПИ это где-то полгода работы до первого измеримого результата (а если человек удачно отмажется, то можно и год результатов не получать, но платить зарплату).
На этот аргумент можно сказать следующее — безусловно эффективность внутреннего ИТ порой не сильно высока, но, на рынке среди интеграторов тоже очень много компаний, команд, мягко говоря сомнительной эффективности. Я бы сказал, что реально качественных намного меньше половины. Продавать то все горазды, а когда дело доходить до выполнения… Только в моей практике, примерно половина клиентов, которые внедряли СЭД, внедряли СЭД не первый раз.
В случае договора с юрмордой все проще: нет результатов — нет бабла. Ну, да, нет и результатов, но хотя бы деньги не потратили.
Ожидаемые же результаты же в случае договора внедрения всегда заранее известны. Прописывать ПИМИ и закрывать работы актами не вчера придумали же.
Нет результатов — это как? Система не внедрена? Не удовлетворяет условиям ПМИ? Тогда верно. Только результат для заказчика обычно не в том, что система установлена и удовлетворяет ПМИ, что пользователи обучены и т.п., а в том, что цели проекта достигнуты и от использования системы есть реальная польза. Вот это результат, но ни в каком договоре с юр.лицом вы не сможете сформулировать и зафиксировать реальную количественную пользу в качестве критерия закрытия работ, этапов. Точнее даже если это удаться сделать, то дурак тот интегратор, что такой договор подписал: ведь реальная польза от внедрения СЭД достигается только при его корректном и качественном использовании и во времени (ну и естественно, при условии что внедрено качественно), и если приоритеты и задачи были выбраны адекватно потребностям бизнеса — а это практически никогда не бывает в компетенции исполнителя.
В общем, я с восхищением смотрю на компании, которые пишут сами под себя аналоги готовых продуктов, но категорически не хочу поддерживать это безумие.
Поверьте, если Вам встречались только неудачные примеры самописных систем, то означает ровно то, что тем кого Вы видели, не повезло. Примеров качесвтенных самописных систем — море, компании их содержащии обычно отдают себе отчет, что в целом содержать такую систему вероятно дороже, но множество факторов говорит в пользу текущего решения. Постепенно с развитием платформ и продуктов на рынке, естественно ценность самописных решений падает, это очевидно. Пропадет ли совсем со временем — не уверен. Я не фанат «самописного подхода», мне наоборот это невыгодно — моя деятельность — внедрение систем на базе платформ высокой степени прикладной готовности. Но это не отменает того факта, что проект создания системы, той же СЭД с нуля — может быть оправдан, успешен и выгоден и такие примеры есть.
Про Директум за сотни тысяч рублей Вы хорошо сказали, спасибо. Сотни тысяч это WSS Docs скорее всего, директум это уже миллионы рублей.
Ну я собственно и написал «как минимум сотни», так сказать, делая запас. В моей практике также большинство проектов за пределами планки 1 млн рублей, но были и за 0,5 млн: для 25 пользователей со стандартными процессами уложится при желании можно. Поэтому написал «как минимум». Для документума сам не встречал случаев меньше 30 млн, но предположил что они могут быть, написав, как минимум.
А вот дропбокс — нет. Он вообще не для этого.
Уже тупо в связи отсутствием концепции маршрутов согласования документа.
У Вас какое-то предубеждение относительно Дропбокса. Согласен, нетиповое средство, но мы как раз и используем, очень удобно. Но как говорится, «на вкус и цвет..»
Извините, а о каких концепциях маршрутов вообще речь в компаниях с 15, 20, 30 людьми? В таком масштабе предприятия эти понятия если и уместны, то они сугубо в решены на неформальном уровне — в таком коллективе что то организовывать, чтобы как то контролировать и подбирать маршруты просто нецелесообразно. Там два, от силы три маршрута всегда и маршрутизация оперативно решается сама по себе.
1) Неправильная диагностика — это проблема исполнителя, а не заказчика.
Это взаимная ответственность: очень часть заказчик не в состоянии адекватно выделить ключевые свои потребности и их значение и влияние, соответственно вводит и себя и всех в заблуждение относительно своих реальных приоритетов. На возможный контраргумент, о том, что качественный исполнитель проведет такой анализ что сам выявит сходу реальные потребности в полном объеме — скажу, что да, верно, только стоить такие работы будут солидно, а у нас в стране к сожалению не привыкли платить много за анализ и консалтинг.
2) Представления о СЭД как об антибиотике — это проблема исполнителя. Он неправильно информирует заказчика о реальном эффекте от внедрения системы. Зачастую это происходит злонамеренно. Это главная причина дурной славы СЭД.
Верно то что зачастую и злонамеренно вводят в заблуждение при продаже в основном. Но в описании этого пункта — речь то не об этом. А о том, что у Заказчика изначально зачастую ожидания вида «вот сейчас куплю, денег вкину, и мне все за меня сделают». Эти убеждения естественно надо разрушать
3) «Пациент» не хочет «лечиться» — в коллективе всегда есть люди, которые будут противиться внедрению системы. Как не странно чаще всего главный противник это те, кто на момент внедрения занимается документооборотом. Причины этого — совершенно конкретные, но это отдельная большая тема…
Так о том и речь — необходимо организовать процесс таким образом, чтобы минимизировать саботаж. Почему Вы называете это утверждение заблуждением или чьим то «косяком»?
4) Нет ответственного — это, как правило, прямое следствие предыдущего пункта.
На самом деле это следствие, простите за банальность, «незрелости» компании в вопросах внедрения крупных проектов.
5) Бюджет «лечения» неадекватен потребности — это проблема имеет то же происхождение, что и проблема во 2 пункте… Редкий исполнитель решиться информировать клиента о реальных расходах на содержание системы документооборота на предприятии. Надо ли объяснять почему?
Понятно, что многие на рынке избегают разговоров о реальных будущих тратах. Очевидно почему. Но в пункте смысл — предупреждение. Там как раз намек, что все не так просто, и потребуется дальнейшие вложения, иногда довольно таки внушительные. Это надо понимать. В чем же заблуждения?
В моей практике, «шаблоны» в СЭД проекте в этом контексте как таковые слабо-эффективны. Они в итоге получаются либо слишком общего характера, что в целях сбора требований не несет никакой пользы для собирающих, либо если детализированные не учитывают конкретную ситуацию, а это часто вводит отвечающего в ступор, он либо не дает ответа на часть таких вопросов, либо отвечает «как то непонятно» :). По факту некий инструмент анкетирования используется, но в каждом новом проекте «анкета» очень сильно перерабатывается каждый раз исходя из первоначального общения о целях, задачах, границах, предпосылках, особенностях компании и т.п.
решили, что куда веселее держать в штате программистов числом 6 штук, и создать аналог на связке пиратской Дельфи и пиратского MS SQL-сервера.
Система писалась два года представляла собой изящный набор костылей, подпорок и синей изоленты. Я приперся к владельцу заведения, показал ему две цифры: зарплата команды программистов за два года с учетом всевозможных отчислений
А что в этом такого плохого? В фундаментальном решении закрывать свои потребности собственными силами написав систему условно с нуля? Ваш пример говорит только о том, что пойдя на такой шаг не удалось в данном конкретном примере добиться качественного результата. Почему так случилось? Да причин может быть много: плохие программисты, плохая организация работ по развитию и написанию функционала, организационные проблемы компании. Все горазды судить о тех или иных проблемах не особо вдаваясь во все их причины. Думаете все «самописные» затеи плохи? Вот Вам контрпример, есть в открытом доступе, при желании можно найти: крупнейшая компания по выручке в Новосибирске, крупнейшая в России в своем сегменте: Катрен. Издревле практически все информационные системы у них самописные, огромный штат разработчиков, причем до сих пор, насколько мне известно. При этом, также в открытом доступе есть высказывания руководства компании о роли ИТ в успехи их бизнеса. Можно ли было в их случае строить все системе на базе платформ высокой степени готовности? Да, наверняка, технически это было осуществимо. Но вот с точки зрения инвестиций, отдачи от них, и рисков того или иного подхода — вопрос то очень спорный. У меня нет данных относительно статистики «успешности» проектов с самописными системами, но пару лет назад натыкался на статистику по проектам на коммерческих платформах — в мире не более 30% внедрений считаются полностью успешными. Как вы думаете, какой процент «достаточно успешных»? Какой процент в России? Как в «самописках», так и в платформенных проектах есть риски недостижения качественного результата, везде высокие, в самописках вероятно выше риски. Это первое. Второе в том, что рассуждая о теме затрат на содержание 6 веселых программистов и как то сравнивая это с коммерческим проектом, вы почему то ( изначально совершенно справедливо сделали упор на дорогое содержании братии разработчиков, что понятно), совершенно обошли внимание тот факт, что вообще то содержание команды у себя внутри это opex'ы (судя по всему порядка 0,5 млн в месяц + -в зависимости от региона и налоговой практики компании), отдача от деятельности которых наступает (если все хорошо) через 3-6 месяцев с начала написания системы (при этом наверняка эти 6 человек не только этой системой в компании занимаются). Коммерческий проект в классическом стиле — это немалые capex'ы на старте + те же операционные затраты во времени (соглашусь, эти opex'ы вероятно намного меньше чем кушают 6 разработчиков, хотя не всегда). В этом случае отдача также возникает примерно в сопоставимый срок. Поэтому что и с чем Вы сравнивали? Двухлетние opex'ы в размере 12 млн рублей (это если программисты только этим и занимались) с одной стороны, а что было на другой чаше весов? Ведь например capex даже в размере 6 млн не факт что лучше ежегодных opex'ов в те же 6 млн, если рассматривать контекст (риски нового внедрения, зависимость от вендора и подрядчика, тут то программисты рядом сидят). Поэтому Ваш пример на текущий момент показывает лишь то, что в конкретном случае самописка возможно была плохо написана, и не 100% факт что решение на 1С: Предприятии, ровно как и на любой другой платформе, было бы лучше. Вы же не станете утверждать что все самописные системы плохие? Также Вы наверняка не станете утверждать что все коммерческие внедрения успешные.
я не верю в существование компаний, где число согласуемых документов в год — менее сотни
А зря, это малый/микро бизнес и нижний сегмент SMB — адекватная основа экономики в современном мире. Вопрос, готовы ли такие компании на серьезный проект СЭД, и нужен ли им СЭД в классическом понимании? Вероятно и там и там «нет».
я плохо понимаю рекомендацию использовать дропбокс в бизнес-процессах вообще и применительно к согласованию документов в частности
Отличный инструмент для нижнего сегмента SMB, по крайней мере если сравнивать с пересылкой файлов по почте (электронной)
что сами внедренцы рассматривают альтернативой ему мсофис и дропбокс, покажу Вашу статью, и вопросы ко мне снимутся
Смотрите, здесь же вопрос не в том, что прикладные инструменты есть аналог коммерческой платформы СЭД. На самом деле странно что Вы сделали такой вывод, ведь четко написано что внедрять СЭД в компанию из 15 человек, да даже из 50, вероятно имелось ввиду классический проект с внешним подрядчиком на коммерческой платформе, согласитесь, как минимум странно. Как минимум с точки зрения затрат. В этих случаях либо строим процессы на основе того, что под рукой (тот же офис и дропбокс, почему нет?), либо существует класс saas-ных недорогих вещей. Аналог этих вещей также можно развернуть локально. Кто станет инвестировать с ходу как минимум сотни тысяч рублей в таких условия в классический проект СЭД (directum/DocsVision/1C)?? Или как минимум миллионы для Documentum/OpenText/FileNet? И зачем он в такой ситуации?
Создается печальное впечатление, что, давая такие рекомендации (мс-офис, дропбокс и тп) Вы вообще плохо представляете себе продукта, который внедряете.
А на самом деле четкая и адекватная оценка, что проект по СЭД не панацея от всех бед и не всем он нужен. Но это очевидно.
Yurich, lair,
С точки зрения состава «противопоказаний» вероятно ничего из вышесказанного не специфично именно для СЭД и перечень наверняка не полон. Специфичность для СЭД можно и следует искать в деталях, в особенностях влияния того или иного фактора именно в этой сфере. Тогда придется отвечать на вопрос: а чем вообще проект внедрения, или в целом специфика СЭД отличается от всех других, допустим от CRM и ERP. Однозначного ответа наверняка на такой, достаточно фундаментальный вопрос, вероятно нет. Со своей «колокольни» мог бы отметить, что в целом процессы, относящиеся к ECM, менее формализованы и упорядочены на практике. Это на самом деле очевидно, ввиду того что «ECM-процессы» как правило с точки зрения основного бизнеса на периферии: мало кто будет спорить что тех. процесс по изготовлению изделия вероятно в конкретной ситуации важнее чем процесс, утрирую, работы с входящей корреспонденцией. Насколько важен процесс бюджетирования, финансового планирования, продаж, относительно скажем процессов работы с ОРД. И с развитием бизнеса прикладным процессам естественно уделяется повышенное внимание. При выборе направлений развития лицо, принимающее решение, с большей вероятностью выберет курс на «реальный сектор» (производственный, финансовый и т.п.) и в этом вероятно глубочайшее заблуждение, так как например, такая сфера, как исполнительская дисциплина и ее контроль, с точки зрения управления, а значит и бизнес в целом, задача первостепенная. С учетом уклона в развитии на предметный, отраслевой сектор, фундаментальные вопросы управления, в т.ч. попытки какой то автоматизации управления, на практике зачастую откладываются «на будущее», позволяя компании как организму все больше и больше «привыкать» к отсутствию понятных и эффективных правил в этом направлении.
С учетом, сказанного, а именно «пониженной» формализации процессов ECM (банально с ходу менее понятно, что же с ними делать), такое противопоказание, как например, «нет ответственного» начинают иметь более острое влияние: насколько компетентен и эффективен будет выбранный ответственный, по сравнению с ответственными для CRM (тут то условно все понятно — ком.дира берем в оборот и все ок). Или «пациент не хочет лечится» к контексте СЭД более острое противопоказание, нежели в ERP (банально практика 3-лет в ERP и 5-ти летняя в ECM позволяет это утверждать, насколько по разному возмущаются пользователи при том и при другом, ну там и охват другой). Поэтому стоит, на мой взгляд, учитывать не состав как таковой, а различность влияния и важности в зависимости от класса систем.
Я думаю разногласия порождены разной точкой зрения на понятия «знать продукт» и разной практикой во внедрении приложений (читай «бизнес-приложений»):
Что значит «знать продукт»? Если имеется ввиду «технические знания в коде, архитектуре и т.п.» то в корне не соглашусь. Так как если БА знал бы это лучше всех остальных, тогда бы справедлив был бы вопрос, утрирую, «А зачем вообще нужны архитекторы, программисты, инженера и т.п.». Ведь по факту, при прочих равных, маленькая проектная команда эффективнее чем большая проектная команда (обратите внимание, при прочих равных, т.е. как минимум маленькая способна справится с таким проектом в нужный срок). Проблема взаимодействия — одна из ключевых, с ростом участников рабочей группы — эффект только усиливается. Для поговорки «Одна голова хорошо, а две лучше» метод математической индукции не действует. Где то на 4-5-ой «голове», она и каждая последующая делают коммуникации все более сложными, нивелируя эффект общей базы знаний и компетенций.
Если «знать продукт» — имеется ввиду его фундаментальные возможности, т.е. перечень задач, которые могут быть решены — то полностью согласен. Единственная оговорка, что в этом смысле «знать продукт» в какой то степени равнозначно необходимости специализации в классе систем, например ECM, так как практически все продукты «класса ECM» в целом предназначены для решения определенного класса задач, пусть с некоторыми особенностями от продукта к продукту, но этих особенностей не «бесконечное число», особенно в терминах возможностей.
Согласен, если бизнес-модель позволяет утилизировать БА в роли инженера внедрения, инженера-программиста, специалиста сопровождения (зачастую это по рынку менее «дорогие» роли) — эффект от плотного знакомства с продуктом (платформой) может действительно быть полезным — как минимум снижение рисков в дальнейшей разработке. Здесь правда есть обратная сторона: классическая задача БА сформулировать требования, реализация которых позволит достичь целей внедрения и по-хорошему, цели и требования должны ставится условно без оглядки на технологию и продукт (это уже потом идет «анализ покрытия№ функционалом сформированных требований и т.п.), так как клиенту по большому счету должно быть все равно, молотком конкретно какой модели строят нужный ему дом исполнители, которым он доверился (раз пошел на сделку). Заказчику нужен результат в виде польз, а не состав продуктов и их возможностей. Отсюда напрашивается вывод: если при формулировании требований БА чрезмерно опирается на возможности платформы/продукта, он по факту решает задачу вида „как же приблизить требования и цели к тому что моя команда сможет реализовать с наименьшими затратами“, а не свою классическую задачу „описание требований, позволяющих достичь целей проекта, которое (описание) позволит разработать и предложить архитектуру решения, которые покрывает эти требования полностью (что маловероятно), либо в достаточно большой степени при адекватных затратах (либо признать задачу невыполнимой и отказаться)“. Соответственно сильный уклон в первый вариант (натягивание „целей“ на базовые возможности продукта) грозит тем, что цели будут достигнуты не полностью, результат не будет соответствовать ожиданиям заказчика, т.е. проект нельзя считать полностью успешным. Хотя с точки зрения бизнеса „внедренца“, в краткосрочной перспективе „малозатратность“ реализации естественно — только в плюс, но в среднесрочной грозит отсутствием действительно хорошего подтвержденного „референса“ и портфолио, если „классическая“ составляющая не соблюдена.
Что касается „дыр в ТЗ“, а здесь имеется ввиду вероятно документ в терминах объектов платформы/продукта (т.е. не концепция, не устав, не функциональные требования), то его составление — коллективная задача БА и архитектора, задача последнего как раз минимизировать количество этих „дыр“, читай рисков реализации.
Относительно госструктур и госкорпораций — не берусь судить, только раз был опыт, больше не хочется, поэтому скорее соглашусь с Вами в этом вопросе.
А потому что пример с автомобилем хоть и красив, но не контраргумент ни разу. :) Покупая машину, я сужу по себе, я ожидаю что она будет адекватно ездить, управляться, и много чего еще. Вы доводите до абсурда, сравнивая эти вещи. А причина исходного ожидания в том, что у нас такой рынок, такова жизнь, увы. Человеку проще все свалить на других с фразой «вы же профессионалы», нежели расписать в своей неспособности поставить четко задачу и организовать свою часть процесса внедрения на своей стороне. И как ни крутите, вы будете вынуждены с этим работать и бесплатно ставить заказчику процесс по внедрению внутренних ИТ-проектов. А потом еще и нести за это ответственность. Бывают исключения и действительно «зрелые» заказчики с поставленными процессами. Но у них давно уже все внедрено :), а если серьезно, то просто очень редко в процентном соотношении.
Конечно, заказчика)
Давайте лучше не заниматься игрой слов. Я думаю очевидно, что формально назначенный ответственный, не исполняющий своих обязанностей, все равно что «нет ответственного». А также Вы наверняка себе отдаете отчет, что ситуации когда ответственного нет даже формально, это какая то дикость и, мягко говоря, маловероятна. Формально назначить формального ответственного и потом формально с него попросить формально ответить за формальный результат, ведь это же не проблема? )
И даже в этом проекте не было очевидной необходимости разделять разные «аналитические» роли между разными людьми, одного ресурса с точки зрения экономической целесообразности было достаточно, это было по силам. Понятно, что в таком случае вынужденная замена такой роли в таком проекте — смерти подобно, но не вижу, насколько сильно бы ситуацию спасло подобное деление. Естественно риски меньше, но, имхо, не значительно, относительно гораздо больших накладных и издержек взаимодействия.
Но не спорю, что при более плотном изучении процесса в компании с потоком действительно крупных проектов, не изменил бы своего мнения.
Спасибо за комментарий.
за ссылочку огромное спасибо! Относительно профстандарта (октябрь 2014?, совсем недавно?) — безусловно часть вопросов снимает, остается только жалеть, что размещать в вакансиях такой перечень — бесперспективно, так как вряд ли кто то откликнется на такой серьезный перечень не запросив за это баснословную сумму :). В регионах это особенно актуально. С точки зрения систематизации требований и понимания подхода к возможному выращиванию — незаменимо. И сам ресурс школы, спасибо за то, что познакомили. Это для меня открытие, что такое в принципе существовало.
На самом деле давно был знаком с разделением понятий и ролей на бизнес-аналитика и системного аналитика. Вся проблема в том, что в существующих рыночных условия бить таким образом эти роли, формируя в команде под эти цели как минимум двух разных людей, учитывая проблемы утилизации и прочие накладны, это грозит поставить под сомнения экономическую эффективность такой модели. Если проект не имеет каких то запредельных масштабов, а особенно если из раза в раз проекты в одной и той же предметной плоскости, имхо, это должен быть всегда один человек в двух ролях. Либо часть роли системного аналитика должна ложится на архитектора.
Спасибо за конкретику. Относительно замечания по «прекрасно считатете» — надеюсь вы без иронии, так как являясь 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 человек в данном случае — это не бизнес и не компания, это простите, какой то пионерлагерь с бесконечным кэшем. И верить что такое случается, ну как то опрометчиво, а тем более приводить где то пример такого «бизнеса» и делать какие-то выводы из этого.
На этот аргумент можно сказать следующее — безусловно эффективность внутреннего ИТ порой не сильно высока, но, на рынке среди интеграторов тоже очень много компаний, команд, мягко говоря сомнительной эффективности. Я бы сказал, что реально качественных намного меньше половины. Продавать то все горазды, а когда дело доходить до выполнения… Только в моей практике, примерно половина клиентов, которые внедряли СЭД, внедряли СЭД не первый раз.
Нет результатов — это как? Система не внедрена? Не удовлетворяет условиям ПМИ? Тогда верно. Только результат для заказчика обычно не в том, что система установлена и удовлетворяет ПМИ, что пользователи обучены и т.п., а в том, что цели проекта достигнуты и от использования системы есть реальная польза. Вот это результат, но ни в каком договоре с юр.лицом вы не сможете сформулировать и зафиксировать реальную количественную пользу в качестве критерия закрытия работ, этапов. Точнее даже если это удаться сделать, то дурак тот интегратор, что такой договор подписал: ведь реальная польза от внедрения СЭД достигается только при его корректном и качественном использовании и во времени (ну и естественно, при условии что внедрено качественно), и если приоритеты и задачи были выбраны адекватно потребностям бизнеса — а это практически никогда не бывает в компетенции исполнителя.
Поверьте, если Вам встречались только неудачные примеры самописных систем, то означает ровно то, что тем кого Вы видели, не повезло. Примеров качесвтенных самописных систем — море, компании их содержащии обычно отдают себе отчет, что в целом содержать такую систему вероятно дороже, но множество факторов говорит в пользу текущего решения. Постепенно с развитием платформ и продуктов на рынке, естественно ценность самописных решений падает, это очевидно. Пропадет ли совсем со временем — не уверен. Я не фанат «самописного подхода», мне наоборот это невыгодно — моя деятельность — внедрение систем на базе платформ высокой степени прикладной готовности. Но это не отменает того факта, что проект создания системы, той же СЭД с нуля — может быть оправдан, успешен и выгоден и такие примеры есть.
Ну я собственно и написал «как минимум сотни», так сказать, делая запас. В моей практике также большинство проектов за пределами планки 1 млн рублей, но были и за 0,5 млн: для 25 пользователей со стандартными процессами уложится при желании можно. Поэтому написал «как минимум». Для документума сам не встречал случаев меньше 30 млн, но предположил что они могут быть, написав, как минимум.
У Вас какое-то предубеждение относительно Дропбокса. Согласен, нетиповое средство, но мы как раз и используем, очень удобно. Но как говорится, «на вкус и цвет..»
Извините, а о каких концепциях маршрутов вообще речь в компаниях с 15, 20, 30 людьми? В таком масштабе предприятия эти понятия если и уместны, то они сугубо в решены на неформальном уровне — в таком коллективе что то организовывать, чтобы как то контролировать и подбирать маршруты просто нецелесообразно. Там два, от силы три маршрута всегда и маршрутизация оперативно решается сама по себе.
Это взаимная ответственность: очень часть заказчик не в состоянии адекватно выделить ключевые свои потребности и их значение и влияние, соответственно вводит и себя и всех в заблуждение относительно своих реальных приоритетов. На возможный контраргумент, о том, что качественный исполнитель проведет такой анализ что сам выявит сходу реальные потребности в полном объеме — скажу, что да, верно, только стоить такие работы будут солидно, а у нас в стране к сожалению не привыкли платить много за анализ и консалтинг.
Верно то что зачастую и злонамеренно вводят в заблуждение при продаже в основном. Но в описании этого пункта — речь то не об этом. А о том, что у Заказчика изначально зачастую ожидания вида «вот сейчас куплю, денег вкину, и мне все за меня сделают». Эти убеждения естественно надо разрушать
Так о том и речь — необходимо организовать процесс таким образом, чтобы минимизировать саботаж. Почему Вы называете это утверждение заблуждением или чьим то «косяком»?
На самом деле это следствие, простите за банальность, «незрелости» компании в вопросах внедрения крупных проектов.
Понятно, что многие на рынке избегают разговоров о реальных будущих тратах. Очевидно почему. Но в пункте смысл — предупреждение. Там как раз намек, что все не так просто, и потребуется дальнейшие вложения, иногда довольно таки внушительные. Это надо понимать. В чем же заблуждения?
А что в этом такого плохого? В фундаментальном решении закрывать свои потребности собственными силами написав систему условно с нуля? Ваш пример говорит только о том, что пойдя на такой шаг не удалось в данном конкретном примере добиться качественного результата. Почему так случилось? Да причин может быть много: плохие программисты, плохая организация работ по развитию и написанию функционала, организационные проблемы компании. Все горазды судить о тех или иных проблемах не особо вдаваясь во все их причины. Думаете все «самописные» затеи плохи? Вот Вам контрпример, есть в открытом доступе, при желании можно найти: крупнейшая компания по выручке в Новосибирске, крупнейшая в России в своем сегменте: Катрен. Издревле практически все информационные системы у них самописные, огромный штат разработчиков, причем до сих пор, насколько мне известно. При этом, также в открытом доступе есть высказывания руководства компании о роли ИТ в успехи их бизнеса. Можно ли было в их случае строить все системе на базе платформ высокой степени готовности? Да, наверняка, технически это было осуществимо. Но вот с точки зрения инвестиций, отдачи от них, и рисков того или иного подхода — вопрос то очень спорный. У меня нет данных относительно статистики «успешности» проектов с самописными системами, но пару лет назад натыкался на статистику по проектам на коммерческих платформах — в мире не более 30% внедрений считаются полностью успешными. Как вы думаете, какой процент «достаточно успешных»? Какой процент в России? Как в «самописках», так и в платформенных проектах есть риски недостижения качественного результата, везде высокие, в самописках вероятно выше риски. Это первое. Второе в том, что рассуждая о теме затрат на содержание 6 веселых программистов и как то сравнивая это с коммерческим проектом, вы почему то ( изначально совершенно справедливо сделали упор на дорогое содержании братии разработчиков, что понятно), совершенно обошли внимание тот факт, что вообще то содержание команды у себя внутри это opex'ы (судя по всему порядка 0,5 млн в месяц + -в зависимости от региона и налоговой практики компании), отдача от деятельности которых наступает (если все хорошо) через 3-6 месяцев с начала написания системы (при этом наверняка эти 6 человек не только этой системой в компании занимаются). Коммерческий проект в классическом стиле — это немалые capex'ы на старте + те же операционные затраты во времени (соглашусь, эти opex'ы вероятно намного меньше чем кушают 6 разработчиков, хотя не всегда). В этом случае отдача также возникает примерно в сопоставимый срок. Поэтому что и с чем Вы сравнивали? Двухлетние opex'ы в размере 12 млн рублей (это если программисты только этим и занимались) с одной стороны, а что было на другой чаше весов? Ведь например capex даже в размере 6 млн не факт что лучше ежегодных opex'ов в те же 6 млн, если рассматривать контекст (риски нового внедрения, зависимость от вендора и подрядчика, тут то программисты рядом сидят). Поэтому Ваш пример на текущий момент показывает лишь то, что в конкретном случае самописка возможно была плохо написана, и не 100% факт что решение на 1С: Предприятии, ровно как и на любой другой платформе, было бы лучше. Вы же не станете утверждать что все самописные системы плохие? Также Вы наверняка не станете утверждать что все коммерческие внедрения успешные.
А зря, это малый/микро бизнес и нижний сегмент SMB — адекватная основа экономики в современном мире. Вопрос, готовы ли такие компании на серьезный проект СЭД, и нужен ли им СЭД в классическом понимании? Вероятно и там и там «нет».
Отличный инструмент для нижнего сегмента SMB, по крайней мере если сравнивать с пересылкой файлов по почте (электронной)
Смотрите, здесь же вопрос не в том, что прикладные инструменты есть аналог коммерческой платформы СЭД. На самом деле странно что Вы сделали такой вывод, ведь четко написано что внедрять СЭД в компанию из 15 человек, да даже из 50, вероятно имелось ввиду классический проект с внешним подрядчиком на коммерческой платформе, согласитесь, как минимум странно. Как минимум с точки зрения затрат. В этих случаях либо строим процессы на основе того, что под рукой (тот же офис и дропбокс, почему нет?), либо существует класс saas-ных недорогих вещей. Аналог этих вещей также можно развернуть локально. Кто станет инвестировать с ходу как минимум сотни тысяч рублей в таких условия в классический проект СЭД (directum/DocsVision/1C)?? Или как минимум миллионы для Documentum/OpenText/FileNet? И зачем он в такой ситуации?
А на самом деле четкая и адекватная оценка, что проект по СЭД не панацея от всех бед и не всем он нужен. Но это очевидно.
С точки зрения состава «противопоказаний» вероятно ничего из вышесказанного не специфично именно для СЭД и перечень наверняка не полон. Специфичность для СЭД можно и следует искать в деталях, в особенностях влияния того или иного фактора именно в этой сфере. Тогда придется отвечать на вопрос: а чем вообще проект внедрения, или в целом специфика СЭД отличается от всех других, допустим от CRM и ERP. Однозначного ответа наверняка на такой, достаточно фундаментальный вопрос, вероятно нет. Со своей «колокольни» мог бы отметить, что в целом процессы, относящиеся к ECM, менее формализованы и упорядочены на практике. Это на самом деле очевидно, ввиду того что «ECM-процессы» как правило с точки зрения основного бизнеса на периферии: мало кто будет спорить что тех. процесс по изготовлению изделия вероятно в конкретной ситуации важнее чем процесс, утрирую, работы с входящей корреспонденцией. Насколько важен процесс бюджетирования, финансового планирования, продаж, относительно скажем процессов работы с ОРД. И с развитием бизнеса прикладным процессам естественно уделяется повышенное внимание. При выборе направлений развития лицо, принимающее решение, с большей вероятностью выберет курс на «реальный сектор» (производственный, финансовый и т.п.) и в этом вероятно глубочайшее заблуждение, так как например, такая сфера, как исполнительская дисциплина и ее контроль, с точки зрения управления, а значит и бизнес в целом, задача первостепенная. С учетом уклона в развитии на предметный, отраслевой сектор, фундаментальные вопросы управления, в т.ч. попытки какой то автоматизации управления, на практике зачастую откладываются «на будущее», позволяя компании как организму все больше и больше «привыкать» к отсутствию понятных и эффективных правил в этом направлении.
С учетом, сказанного, а именно «пониженной» формализации процессов ECM (банально с ходу менее понятно, что же с ними делать), такое противопоказание, как например, «нет ответственного» начинают иметь более острое влияние: насколько компетентен и эффективен будет выбранный ответственный, по сравнению с ответственными для CRM (тут то условно все понятно — ком.дира берем в оборот и все ок). Или «пациент не хочет лечится» к контексте СЭД более острое противопоказание, нежели в ERP (банально практика 3-лет в ERP и 5-ти летняя в ECM позволяет это утверждать, насколько по разному возмущаются пользователи при том и при другом, ну там и охват другой). Поэтому стоит, на мой взгляд, учитывать не состав как таковой, а различность влияния и важности в зависимости от класса систем.
Что касается „дыр в ТЗ“, а здесь имеется ввиду вероятно документ в терминах объектов платформы/продукта (т.е. не концепция, не устав, не функциональные требования), то его составление — коллективная задача БА и архитектора, задача последнего как раз минимизировать количество этих „дыр“, читай рисков реализации.