Pull to refresh

Comments 38

Я списывался с админами данного блога они из «железного» направления EMC, будучи сотрудниками большой конторы, они подозревают знают о существовании Документума, но как выглядят их коллеги и обитают ли они в Хабре, не знают.
Кстати, Студия Лебедева показала половину интерфейса СЭД «Интертраст» на пресс-завтраке :)

По теме: во-первых, действительно интересно будет прочитать о «кухне» внедрения различных систем — какие проблемы были, как здорово они решились, как система работает в компании через год-два.

А еще очень интересны отзывы пользователей различных СЭД: не хвалебные (написанные компанией-вендором для пресс-релиза с согласия клиента), а объективные: что нравится и не нравится, что удобно, а что раздражает. А если проект «не сросся» и закупленные лицензии СЭД до сих пор лежат на полке — почему так получилось.

Ведь информации о том, как волшебно у компании получилось реализовать тот или иной проект — море, а о проблемах самих пользователей, которым, возможно, какая-то система не облегчила работу, а совсем наоборот — чуть.
Полинтерфейса — это сильный маркетинговый шаг. Вот и спрашивается, где видео-отчет, презентации с «живыми» интерфейсами?
Увидев всего полинтерфейса, теперь я никогда не смогу использовать обычные СЭД!
Причинами всех вышеперечисленных проблем является нежелание как пользователей СЭД, так и создателей обнажать свои слабые стороны, ведь это бьет по имиджу компании. Также, довольно часто такие вопросы выносятся в договоре в раздел о неразглашении.
При обсуждении картинки для этого поста я голосовала за картинку с обиженно-негодующей собачкой, а не с мужчиной в галстуке. Считаю, что собачка ассоциируется и с СЭДами, которые very sad, и с конкурентной грызней, которая имеет место в СЭД-среде :)
Ситуация пока такова, что тот кто больше всех кричит, тот и прав. Сложно представить себе техспециалиста заказчика, который соберет полные требования к системе, проведет тщательное исследование рынка, установит у себя и протестирует 3-4 демо-версий наиболее соответствующих систем и проведет обоснование выбора руководству. Это огромные ресурсные и временные затраты, на которые идут не все потенциальные заказчики. Проще выбрать систему наиболее убедительного (распиаренного с многочисленными внедрениями) поставщика. Отсюда и конкурентная грызня.
а о чем вообще можно написать про СЭД со стороны разработчика?
Написать можно много. Скажем, поделиться опытом создания и внедрения продукта. Сравнить собственную систему с продуктами других разработчиков. Рассказать о перспективах развития собственной системы.
может я не правильный разработчик, но причем тут внедрение и разработка. у нас этим занимаются разные люди. я ведущий программист, и на мне только чистая разработка и развитие продукта. Никаким внедрением не занимаюсь. При внедрении не требуется навыков программиста. Система достаточно гибкая и может быть настроена как угодно.

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

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

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

получается что неизменным остается основной интерфейс системы, и общее расположение элементов, а то какие модули системы будут располагаться в определенных частях страницы так же определяет клиент сам
а говорите не о чем рассказывать :)
Хорошо, посмотрим может и попробую наскребсти на статью
Вот так, с развитием СЭД-тематики на Хабре, глядишь, и доселе неизвестные писатели проявятся :)
Пишите, и не забудьте позвать на обсуждение. В одиночку такие вопросы не поднять.
Дмитрий, в вашем случае, например, о том как вашей системе работается с Cache' и как ее постреляционность или другие аспекты помогают в разработке именно СЭД-задач.
В общем случае, про менеджмент проектов/продуктов, маркетинг, продажи, управление компанией, персоналом, про интерфейсы — вообще непочатый край вопросов.
На Cache` работается замечательно, помогает по большей части именно ее постреляционность, потому как даже имея Cache` SQL, и его практически не используем, только в некритичных для быстродействия местах.

есть проект когда объем всех данных занимает уже больше 5TB, все работает быстро.
есть и большим количеством пользователей в несколько тысяч, с откликом системы в среднем 5 секунд
Дмитрий, вот безумно интересно было бы услышать подробнее на эту тему на самом деле
В этих 5TB есть большие файлы (>100 мб) и они хранятся в СУБД?
Размер файла не имеет значения, все они хранятся в самой СУБД, для данного проекта как раз это было одним из основным факторов по которому они выбрали именно нашу СЭД, а с учетом того что наше приложение частично интегрируется в интерфейс уже используемого у них приложения, то было еще лучше. По факту они используют только один конкретный вид документа, который открывается по сформированной авторизованной ссылке, не открывая интерфейса всего СЭД.
Хабру не интересно — вот и всё. У программеров, мало понятные обычным пользователям механизмы обмена информацией: системы контроля версий, багтрекеры, вики и всякие там бейскампы\редмайны с плагинами. Им СЭД не нужны, как результат — на Хабре о них не пишут и не читают.
Согласно вашему посту получается что Хабр читают только программисты. ЧТо не очень согласуется с разнообразием информации на Хабре.
Ну почему же? Хабр развивается, среди читателей и пользователей появляются люди самых разных интересов и занятий. Кроме того, через призму СЭД можно рассмотреть много важных и интересных проблем управления информацией.
Дык никто не просит рассмотреть систему управления корпоративным контентом в качестве системы сбора требований или багтрекера. Я приглашаю, как минимум, обсудить СЭД/ECM как объект разработки и внедрения. Такие статьи на Хабре есть и они весьма популярны, просто их крайне мало.
Давно занимаюсь внедрением СЭД на Documentum, но вот писать об этом совсем не хочется, т.к. проекты на самом деле никому не нужны, хотя конечно внедряются, но не для оптимизации расходов организации, а с другой целью.
С другой целью, говорите? Не могли бы Вы рассказать, с какой именно…
ikirin, случайно ответила вам выше уровнем.
Откаты понятное дело. Чтобы СЭД был эффективен нужно менять бизнес-процессы (БП), а это значит увольнять нужно народ. Никто на это идти не хочет. Как правило внедрение СЭД без оптимизации БП делает делопроизводство еще сложней. Вот и спрашивается зачем такая система нужна?
1. Про откаты не совсем понятно. У вас есть подтвержденные факты получения откатов на реализации тех или иных проектов? Или просто слухи?

2. Ни разу не видел чтобы в результате успешных внедрений информационных систем увольнялись люди.

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

2. Я про то, что после внедрения, некоторые должности необходимо сократить. Что в это случае делать с людьми? Придумать им новые должности?

3. У нас тут проблема в терминологии :) Я о сложности = трудоемкости, т.е. возрастает нагрузка на сотрудников делопроизводства в 2 раза, если не менять БП. Их это реально злит.
По последнему пункты могу привести кучу примеров из нашей практики:

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

Пример 2. Согласовываем интерфейсы будущей информационной системы с маркетинговым отделом ВУЗа. Начальник отдела первым делом задает вопрос: «Придется ли мне делать больше того, что я уже делаю, например, заполнять данными систему? Если да, то я работу в системе буду игнорировать. В должностных инструкциях у меня нет обязанностей заполнять какой-то электронный архив».

Работы для рядовых сотрудников по факту внедрения информационной системы в любом случае станет больше и она будет сложнее.
Если Documentum внедряется, значит это кому-то нужно. Другой вопрос, что реальные цели и задачи различных сотрудников заказчика могут сильно отличаться от «оптимизации расходов организации». Могу высказать как минимум пару таких причин.

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

Со вторым примером лично не сталкивался, но рассматриваю как весьма вероятный. Внедрение известной зарубежной информационной системы корпоративного уровня, будь то ERP или ECM системы, повышает прозрачность и привлекательность кампании для внешних, особенно зарубежных инвесторов.
Мне кажется, вы только что сами сформулировали один из возможных тезисов для статьи по Documentum ;)
Процитирую комментарий коллеги, написанный на другом форуме:

Хелен:
Полностью согласна с предоставленным анализом интернет-ресурсов и благодарна за него Причиной СЭД-тухляка на Хабре считаю невовлеченность пишушей братии Хабра в тему_СЭД. А самыми интересными темами для себя выделяю – правдивые истории про живые проекты, про то, как происходило все, и чем все завершилось, и почему.
Sign up to leave a comment.