Несмотря на кажущуюся очевидность утверждения «главный компонент приложения на базе СЭД — документ, а то, что оно автоматизирует – его «оборот», на практике оказывается, что под документом в приложениях могут иметься в виду самые различные сущности. Зависит это от типа документа и характера его «оборота», т.е. жизненного цикла обработки. Docsvision обеспечивает механизмы для реализации таких объектов. Связано это с тем, что даже для самых типовых приложений СЭД (например, для автоматизации задач классического делопроизводства) нам было необходимо моделировать в системе документ, который описывается очень сложной структурой данных и сложным жизненным циклом. Возможность моделировать такие сложные сущности как документ в делопроизводстве и позволила нам приобрести достаточную универсальность в реализации приложений для обработки документов различной природы. Держа в голове соображения, высказанные в предыдущей статье, попробуем описать модель сущности, которую мы называем словом «документ».

Среди разработчиков мобильных приложений B2C и B2B сегментов широко обсуждаются достоинства и недостатки альтернативных подходов к архитектуре клиентского приложения – делать его на HTML, нативным или гибридным (простой нативный клиент, открывающий встроенный браузер для обмена данными с сервером).
Одна из первых статей Microsoft на эту тему была опубликована на MSDN в 2012 году и не потеряла своей актуальности до сих пор (Choosing between a web and native experience). В этой статье мы рассмотрим использование гибридного варианта мобильного приложения для СЭД.

Вопрос о том, как ставить задачи и оценивать трудозатраты техписателей, поднимается почти на каждом вебинаре, конференции и встрече, посвященной документированию. В чем сложность? Почему, в отличие от оценки времени, затраченного программистами, тестировщиками и другими сотрудниками отдела разработки, именно трудозатраты документаторов постоянно вызывают дискуссии?
Попробую объяснить и показать, как можно избежать проблем в этом вопросе, используя систему управления задачами (как это работает — покажу на примере используемой нами системы Actionspace). Технический писатель, Лена Толмачева.

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

Привет, Хабр! Мы продолжаем изучать последнюю версию системы EOS for SharePoint, вышедшую в ноябре прошлого года. В первой части статьи мы рассказывали о новых функциях, изменениях, конкурентных преимуществах, дополнительных опциях и подсистемах программы, переходе со старой версии на новую. Сегодня речь пойдёт об изменениях в интерфейсе и дизайне, улучшении юзабилити, а также планах на будущее.

Привет, Хабр! В сегодняшней статье мы расскажем о новых и измененных функциях EOS for SharePoint 2013 от компании «Электронные офисные системы» в разрезе пользовательской и технической эксплуатации, о преимуществах новой версии по сравнению с продуктами конкурентов, о новых и планируемых дополнительных опциях и подсистемах, о процедуре миграции со старых версий до EOS for SharePoint 2013, а также о пользовательском опыте первых клиентов.

Привет, Хабр! Сегодня мы хотим поговорить о принятии решений — но в психологическом смысле, а в самом практическом, бюрократическом смысле. Думаем, все, кто работал в компнии, в которой больше 20 сотрудников, знакомы с подводными камнями принятие решения в них. Психология тут бессильна: чем крупнее организация, тем сильнее в ней сроки совместного принятия решений зависят от внутренних регламентов, количества принимающих решение, быстроты их реакции и степени автоматизации процесса. В этом посте мы хотим рассказать о том, как устроена функция согласования и подписания электронных документов в нашей системе электронного документооборота (СЭД) EOS for SharePoint: на кого она ориентирована, что из себя представляет, и как настраивается.


Цепочка согласований не должна напоминать лабиринт без выхода

Этим постом я начну небольшой цикл статей, посвящённых различных аспектам разработки приложений в системе электронного документооборота. Сегодня все более или менее мощные и современные СЭД/ECM-платформы содержат набор компонентов и инструментов для их реализации, и именно приложения, создаваемые на базе платформы, позволяют автоматизировать все разнообразие рабочих процессов клиента. Я расскажу о модели приложения платформы Docsvision, о компонентах и средствах разработки (настройки) этих приложений, о том, какие проблемы возникали у нас при реализации инструментария для их разработки, и о том, чего ждём в дальнейшем. Это будет интересно не только тем, кто плотно работает с Docsvision, но и позволит почерпнуть опыт тем, кому предстоит внедрять или развивать свою корпоративную СЭД.

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

Чтобы контроль производительности системы проводился в обоих направлениях, администратору системы нужны удобные инструменты для замеров, позволяющие вовремя найти слабое звено и предпринять меры по улучшению быстродействия. В этой статье я поделюсь своим опытом в том, как можно решить вопрос автоматических замеров показателей быстродействия системы на примере системы электронного документооборота*.
В отличие от других программных продуктов, для СЭД существуют определённые требования по быстродействию: это один из важных параметров, за которым необходимо следить.

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

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

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



Мы в Alconost перевели для вас эти советы и даже добавили пару слов от себя в примечаниях. Правда, цифры прогнозируемого роста продаж, указанные автором для каждого из советов, нам показались недостаточно обоснованными — но суть ведь не в них.

Доброго времени суток.

Изложить свои мысли о теме настоящей публикации натолкнула вполне насущная, «жизненная» необходимость — постепенно приближается время, когда возникнет потребность искать/нанимать на открытом рынке бизнес-аналитиков в штат компании (бизнес в области автоматизации процессов управления документами, контроля исполнительской дисциплины и т.д., в «простонародье» — СЭД). Все специалисты этого профиля, опыт и компетенции которых известны, иными словами тех кого знал и кого видел полезным для компании, либо уже в команде, либо устроены тоже неплохо. Проблему осложняет тот факт, что сколько ни старался, не получается сформулировать кратко и адекватно компетенции, особенности, которыми данный субъект должен обладать. Какие личные качества и таланты должен проявлять — что тоже актуально, так как морально подготовился к тому, чтобы искать талантливых новичков и пытаться их «выращивать». Уверен, что размышления ниже по тексту будут полезны менеджерам проектов, собственникам небольших ИТ-компаний интеграторского типа, да и самим бизнес-аналитикам.

За много лет работы на рынке систем электронного документооборота наша команда сталкивалась с самыми разными проектами. Были среди них и такие, что уже в процессе предпроектной подготовки становилась ясно: компания к внедрению СЭД не готова и система только навредит. Был у нас и опыт «реанимации» чужих проектов внедрения СЭД. В результате мы сформулировали общие принципы «противопоказаний» к внедрению системы электронного документооборота, которыми и хочу поделиться.

2006 год. На форуме специалистов SQL неожиданно поднимается вопрос о целесообразности моделирования бизнес-процессов в CRM-системах. Звучат слова: долго, дорого, Siebel, не нужно, сложно.
2014 год. Все чаще клиенты просят посоветовать CRM с возможностью построения и запуска бизнес-процессов. В чем причина? Первое подозрение — где-то услышали и теперь тянутся за модой. На вопрос «Зачем?» поступает взвешенный ответ: «Устали от беспредела и путаницы в организации работ. Хотя бы в часто повторяющихся действиях нужен порядок». Нельзя не согласиться с тем, что основное назначение регламентации бизнес-процессов в компании — именно порядок. Признайтесь, приятно осознавать, что многие процессы в организации проходят четко, слаженно, быстро, с минимальной нервозностью.

«Агитировать разработчиков за agile – все равно, что рассказывать, что Земля круглая. Да, еще встречаются заказчики, предпочитающие долгий и нудный процесс по ГОСТу (он же waterfall) с производством тонн документации, которую никто никогда читать не будет, но обычно в таких проектах истинной целью является не создание реально работающей системы, а правильно оформленное расходование бюджетных средств.

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



Статья журналиста-аналитика Станислава Макарова.

Понятие BPM (Business Process Management) все более плотно входит в жизнь больших и малых корпораций. Суть его в том, чтобы рассматривать бизнес-процессы компании, как активы, используя которые можно увеличить прибыльность своего бизнеса. Инструмент, который вы для этого используете, может быть любым: лист бумаги, текстовый документ, Visio или любое другое средство создания диаграмм… Но есть класс инструментов, которые специально предназначены для того, чтобы послужить инструментом для трансформации вашего бизнеса — это BPM-платформы.
Задача для такой платформы ставится двояко: с одной стороны необходимо визуализировать бизнес-процесс, а с другой стороны — его нужно исполнить.



Я не буду описывать весь рынок таких платформ, это неплохо сделано в статье независимого агентства Gartner, откуда я взял иллюстрацию выше (полный текст можно скачать с сайта Pega или IBM, но потребуется регистрация, или нагуглить самостоятельно по заголовку: “Gartner BPM Magic Quadrant 2014”).
Цель же данной статьи — провести сравнение технических возможностей двух лидирующих платформ, Pega и IBM BPM, доступных на текущий момент (осень 2014), с точки зрения опыта их использования в проектах по автоматизации бизнес-процессов.

Если вы задумали трансформировать свой бизнес или вам нужно IT-решение, которое позволит достичь бизнес-целей, поставленных высшим руководством, или вы просто интересуетесь BPM-решениями, то добро пожаловать под кат.

Эта статья представляет собой синтез пятилетнего опыта работы консультантом в области корпоративного документооборота в среде SAP. Мой опыт ограничивается только одним вендором — OpenText (Канада), но в последние годы эта технология становится все более и более популярной, в связи с чем и появилось желание опубликовать этот материал.

В статье описана технология работы с неструктурированными документами (сканы документов, электронные оригиналы в формате MS Office и т.д.) в среде структурированных электронных документов — транзакций SAP. Описаны как технический аспект, так и основные бизнес-сценарии работы с документами. Публикация будет полезна всем начинающим (и не очень) консультантам по документообороту, работающим на проектах SAP. Материал был написан практически «из головы», в качестве некоей шпаргалки, или методички.

Публикация здесь — это желание поделиться со всеми специалистами, чтобы передать свой опыт молодому поколению. Я отчётливо понимаю, что ни один учебный курс или методичка не позволят отдельно взятому человеку (сферическому консультанту SAP/ECM в вакууме) взять и выполнить для заказчика проект «под ключ». Поэтому опубликованный здесь материал я рассматриваю в качестве экономии драгоценного человеческого времени. Ну и рад критике, разумеется!

Постановка задачи

Одной из неотъемлемых частей любой ECM-системы является управление бизнес-процессами, или workflow.

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

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

Это диктует некоторые требования, которые предъявлялись к движку бизнес-процессов:

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

При разработке новой версии движка бизнес-процессов мы решили попробовать Windows Workflow Foundation (далее WF).

Часто после внедрения системы электронного документооборота (СЭД) компания сталкивается с неожиданным препятствием: сотрудники против. Неудивительно, ведь людям в одночасье приходится покидать зону комфорта и играть на работе по новым правилам вместо привычных и устоявшихся. Кому на деле выгодно и удобно работать в СЭД, а кому внедрение может доставить реальные неприятности?

Четыре года назад я увидел вакансию инженера по внедрению. Из словосочетания «инженер по внедрению» я мог сделать только очень общий вывод, чем занимается этот специалист. Но т.к. в требованиях было указано знание C# и необходимость писать код, я решил попробовать себя в этой роли. Звезды совпали удачно, и меня позвали на работу.
Как выяснилось в дальнейшем, понятие «инженер по внедрению» так же, как «программист», объединяет в себе очень много разных, но родственных вещей. Все внедренцы так или иначе устанавливают и настраивают «нечто» под требования конечного заказчика. Но областей внедрения так много, что специфику каждой расписать мне кажется невозможным.
В этой статье я постараюсь описать, почему вам может быть интересно стать инженером по внедрению. Если быть точнее, то инженером по внедрению какого-либо ПО, потому что сфера внедрения «железа» для меня — темный лес. Обращаю также внимание на то, что мой личный опыт может быть довольно однобоким.

Добрый день! Меня зовут Михаил. Имея многолетний опыт работы в проектах внедрения различных систем автоматизации (и документооборота, в частности), я часто сталкиваюсь с тем, что неготовность компании к проекту внедрения на самом начальном этапе влечет за собой существенные сложности его реализации. Хотел бы поделиться своими наблюдениями и дать несколько рекомендаций тем, кто планирует заниматься внедрением систем документооборота. Я бы мог дать ряд рекомендаций и компаниям-интеграторам, но сегодня сделаю акцент на другом: на что стоит обратить особое внимание ИТ-специалисту со стороны заказчика. Заблаговременное выявление слабых мест (несмотря на всю их кажущуюся очевидность) поможет вам избежать сложностей в дальнейшей реализации проекта.
Приведу ряд случаев из собственной практики (возможно, некоторые читатели узнают в примерах себя – но все совпадения случайны!)