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

Были и есть форумы на GotDotNet.ru (сейчас лежит) и MSDN\Technet, но оба сфокусированы на вопрос-ответ и населены новичками, которые пытаются сделать что-то нехорошее.

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

Присоединяйтесь к https://www.facebook.com/groups/sharepointrussian/

Знаете ли вы, что за все годы существования индустрии разработки ПО не было выявлено сильной связи межу опытом работы и качеством кода и продуктивностью сотрудника?

В 1968 году было проведено исследование продуктивности работы программистов (источник), которое показало что соотношение лучших и худших программистов составило:

• 20:1 по времени написания кода
• 25:1 по времени отладки кода
• 10:1 по скорости работы программы
• 5:1 по объему кода

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

Но это было давно и в исследовании куча ошибок...

Аналогичные исследования повторялись другими группами ученых на протяжении 30 лет:

• Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.
• Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.
• DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.
• Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.
• Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.
• Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.
• Valett, J., and F. E. McGarry. 1989. "A Summary of Software Measurement Experiences in the Software Engineering Laboratory." Journal of Systems and Software 9, no. 2 (February): 137-48.
• Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.

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

Что это значит?

С 1968 года в разработке улучшилось буквально все: языки, фреймворки, инструменты, а также программированию теперь обучают несколько лет в вузе. Тем не менее продуктивность программистов как отличалась в разы 30 лет назад, так и отличается сегодня.

Это наводит на мысль, что есть некоторый икс-фактор, не связанный с опытом, который отличает хорошего программиста от плохого. На сегодняшний момент нет единого мнения что это за фактор. Одни говорят что это умение планировать свою работу и “видеть” структуру кода еще до того, как код написан. Другие говорят, что самые продуктивные программисты те, кто умеет быстро выдавать видимый результат. Мои личные наблюдения говорят о том, что лучше всего пишут код те, кто умеет читать код.

И что теперь делать?

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

Еще один вывод, который немного противоречит логике, но часто встречается на практике: программист не станет более продуктивным, получив годы опыта. Единственный способ улучшить продуктивность и качество кода программистов – проводить целенаправленное обучение и тренировку .

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

Заключение

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

Аббревиатура EIM – Enterprise Information Management заменила в презентациях экспертов хорошо нам знакомые три буквы ECM. Вроде бы небольшая разница, Information вместо Content — а что стоит за этой игрой словами? Очередной маркетинговый трюк или смена парадигмы? Надеюсь, никто не хочет проспать революцию и остаться со старым продутом на руках, когда рынок двинется вперед, поэтому лучше разбираться с новыми идеями по мере их поступления.

Два мира, два детства

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

Когда железный занавес рухнул, оказалось, что у нас много общего — мы также чувствуем и переживаем в похожих жизненных ситуациях, разве что «москвичей испортил жилищный вопрос». Также и с данными – одни методики и технологии являются общими, как, например, workflow, архивирование и аналитика; другие можно с успехом распространить на любые данные, будь они неструктурированными или структурированными – ERM, таксономия, eDiscovery.

Forrester изображает концепцию EIM в виде штанги, где блинами являются технологии управления разными видами данных, а гриф — это базовые технологии управления информацией, применимые для структурированных и неструктурированных данных. Не будем забывать, что на самом деле наша штанга обладает асимметрией: 80% корпоративных данных — неструктурированные. Поэтому неудивительно, что из ECM наследуется большее количество технологий управления информацией, которые просто напросто обобщили для работы со структурированными данными.

Mind the gap

Организациям нужно целостное управление информацией, без этого разделения на структурированные и неструктурированные. (А куда девать «полу-структурированные»? – иногда и такое встречается в бумагах аналитиков.) Это и объясняет рост интереса к EIM, который мы сейчас наблюдаем. Однако, в исследовании Forrester только 13% компаний ответили, что у них есть единая стратегия управления информацией, нацеленная на все типы данных.

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

Зачем это нужно

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

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

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

Будем есть слона по частям

Едва ли CIO кинутся инвестировать сразу значительные средства в новую концепцию EIM, несмотря на ее очевидные преимущества. Время глобальных и супер-дорогих проектов, очевидно, прошло. Да и задача является слишком сложной, даже если брать только отдельные ее срезы.

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

Что EIM значит для индустрии ECM

Возможно, это второе дыхание индустрии ECM, которая сейчас достигла зрелости. EIM открывает новые горизонты для применения технологий управления контентом на структурированных данных, бывших ранее вне зоны нашего внимания. По сути, какая разница, представлен ли документ в виде скана бумажного оригинала или в виде записи в базе данных ERP – общие принципы и правила управления информацией применимы в обоих случаях. А в ECM практики на эту тему наработано гораздо больше, чем в других бизнес-приложениях, так что можно поделиться опытом с коллегами.

Это несколько вольный пересказ (с моими дополнениями) публикации Генри Уорчестера (Henry Worcester) на портале CMSWire. Оригинал здесь:http://www.cmswire.com/cms/information-management/forrester-links-structured-and-unstructured-information-in-new-eim-framework-021868.php

(картинка отсюда)

Именно такое отношение к лучшим практикам встречается чуть менее, чем всегда. Можно подумать что не все знают про эти best practices. Но как только человек делает что-то не так, ему сразу же указывают как делать правильно. И что после этого происходит? НИЧЕГО. Только единицы начинают делать правильно после того как узнают про best practices, остальные продолжают жрать кактус и плакать о плохих менеджерах\вендорах\подрядчиках\клиентах\государстве.

Почему так происходит?

1. Люди последовательны. Если человек уже что-то делает одним образом, то существует психологический барьер делать по-другому.
2. Люди избегают потерь. Потому что в "другой путь" уже вложено много сил, и есть психологический барьер отказаться от этих "результатов" и пойти правильным путем.
3. Люди не хотят быть неправыми. Есть у людей такой психологический механизм, который рационализирует любое нерациональное поведение. Даже если первоначальные действия были просто ошибкой, то человек придумает 100500 причин почему этот путь был самым правильным.

Вывод

Если кто-либо (в том числе Вы) не следуете best practices, то для этого почти никогда нет никаких рациональных причин. Когда следующий раз вы узнаете про лучшие практики в вашей области и подумаете "это мне не подойдет потому что...", остановитесь, и еще раз взгляните на картинку в начале поста.

Пост-перевод http://veroniquepalmer.com/2014/01/16/your-sharepoint-perception/

Не правда ли, что мы склонны видеть мир через через призму нашего опыта, но не так, как на самом деле. Возьмите SharePoint например ...

• Если вы пришли из области автоматизации работы, то SharePoint всего лишь движок workflow.
• Если вы пришли из области работы с документами, то SharePoint всего лишь хранилище документов с метаданными.
• Если вы пришли из области веб-дизайна, то SharePoint обязательно надо брендить.
• Если вы пришли из области разработки, то SharePoint обязательно требует кастомизации.
• Если вы пришли из области обработки данных, то SharePoint всего лишь панели монтиторинга.
• Если вы пришли из области обучения, то SharePoint можно использовать только после обучения.
• Если вы пришли из области управления, то SharePoint работает только если есть регламенты.
• Если вы пришли из области бизнес-анализа, то SharePoint требует годы планирования.
• Если вы пришли из области социальных медиа, то SharePoint можно использовать только с версии 2013.
• Если вы пришли из области разработки расширений, то SharePoint может работать только вашим самым продаваемым продуктом.

И так можно продолжать очень долго.

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

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

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

Компания «КС-Консалтинг» реализовала уникальный масштабный проект внедрения облачной системы «О7.ДОК» в системе медицинских учреждений Владимирской области. Заказчиком проекта выступило Государственное бюджетное учреждение здравоохранения особого типа «Медицинский информационно-аналитический центр» (МИАЦ), который занимается на территории области организацией сбора, обработки и анализа данных о системе здравоохранения, кадрах, деятельности медицинских учреждений и состоянии здоровья населения.

Система «О7.ДОК» по модели SaaS является совместной разработкой компаний «Ростелеком» и «Электронные Офисные Системы» (ЭОС). Как и другие решения класса СЭД/ECM, облачный сервис «О7.ДОК» предназначен для ведения электронного документооборота, автоматизации бизнес-процессов и управленческих функций предприятия.

Применение модели SaaS (software as a service) подразумевает предоставление заказчику интернет-доступа к программному обеспечению, размещенному на удаленном сервере поставщика услуг. При этом провайдером таких услуг выступает компания «Ростелеком», предоставляя сервера и доступ к ПО через защищенные каналы, в то время как компания ЭОС и ее партнеры выполняют весь комплекс работ по внедрению, настройке и технологическому сопровождению СЭД.

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

Проект внедрения СЭД «О7.ДОК» в ГБУЗ Владимирской области «Медицинский информационно-аналитический центр» был запущен в декабре 2012 г. в рамках программы модернизации здравоохранения области на 2011-2013 гг. Основной целью проекта стала организация обмена электронными документами посредством защищенных каналов связи между МИАЦ, Департаментом здравоохранения и всеми подведомственными лечебно-профилактическими учреждениями (ЛПУ) Владимирской области.

Первой стадией развертывания проекта стало обеспечение технической возможности подключения лечебных учреждений к защищенной ведомственной сети передачи данных. В конце апреля 2013 года прошло совещание представителей МИАЦ и компании ЭОС, где были выдвинуты все требования к развертываемой системе, а также определён исполнитель проекта – компания «КС-Консалтинг», партнер ЭОС на территории Сибирского федерального округа. Выбор сибирской компании был не случайным – из всех партнеров ЭОС именно «КС-Консалтинг» является, пожалуй, самым опытным интегратором систем, выстроенных на базе платформы eDocLib. К тому же специалистами компании создано собственное прикладное решение на базе данной платформы – «eDocLib: АктивБизнес», предназначенное для предприятий среднего и малого бизнеса.

До внедрения системы учет документов в органах здравоохранения Владимирской области осуществлялся в регистрационных журналах, в то время как обмен документами происходил, как правило, в виде бумажных копий, а также путем пересылки отсканированных документов по электронной почте. Такая схема движения предполагает неоправданную трату времени участников документооборота, является не прозрачной и накладывает определенные риски потери документов. Все это явилось предпосылкой необходимости автоматизации и упорядочения документооборота, сформировав перед руководством МИАЦ основные задачи внедрения СЭД:

• перевод регистрации документов в электронный вид, организация обмена электронными документами;


• автоматизация полного жизненного цикла документа;


• сокращение времени поиска нужной информации за счет систематизации и классификации зарегистрированных в системе документов;


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


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

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

Сформированная в результате обследования модель работы с документами стала основой для написания регламента работы в единой системе электронного документооборота (ЕСЭД). Поскольку «О7.ДОК» - это облачная система, не требующая установки ПО и СУБД на рабочих местах и сервере организации-заказчика, весь предполагаемый для стандартного внедрения системы объем работ был заменен не продолжительным по времени развертыванием пула и узла «О7.ДОК» на сервере компании «Ростелеком». Это позволило значительно сократить сроки реализации и материально-финансовую базу проекта. Завершив обследование действующего документооборота, сформировав все необходимые инструкции и модели работы с документами, специалисты «КС-Консалтинг» сразу же приступили к настройке системы.

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

Движение регистрационной карточки в рамках ЕСЭД осуществляется при помощи таких инструментов, как выдача и контроль поручений различного типа: «Резолюция», «На рассмотрение» и «На ознакомление». При этом поручения группы «Резолюция» предусматривают создание отчета о проделанной работе, в то время как другие поручения выдаются без требования отчетности. Также в ЕСЭД «О7.ДОК» была налажена внутренняя пересылка документов между пользователями системы.

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

Об первых итогах внедрения решения «О7.ДОК» в своем интервью рассказала Мария Дегтерева - директор ГБУЗ ВО «МИАЦ» (г. Владимир): «…На сегодняшний день мы внедрили полностью электронный документооборот в Медицинском информационно-аналитическом центре г. Владимира, где установлено около 40 рабочих мест. Начали, конечно, с руководителей, я сама прошла обучение. Теперь все поручения идут через «О7.ДОК», а секретарь настолько трепетно относится к работе с данным решением, что у нас теперь из МИАЦ не уходит ни одного документа, если он не зарегистрирован в системе. В целом, первый этап внедрения затронул 112 лечебных учреждений или 352 пользователей (технологи, руководители, секретари). Вторым этапом внедрения «О7.ДОК» будет охвачено еще больше пользователей…»

Говоря о перспективах развития ЕСЭД, Мария также отметила: «…Что касается текущей эволюции, то сегодня мы занимаемся интеграцией электронного документооборота с web-отчетностью. Дело в том, что у нас существует web-портал, где каждое лечебное учреждение обязано заполнять специальные отчеты и мониторинги, – весь процесс контролируют наши специалисты. В случае же, если портал будет интегрирован с системой электронного документооборота, контроль будет осуществляться эффективнее, – специалисты МИАЦ будут полностью уверены в том, что сотрудники учреждений получали письмо с требованием заполнить отчет…»

Ознакомиться с полным текстом интервью можно здесь: https://www.eos.ru/eos_news/detail.php?ID=121498

Первая часть этой серии была написана примерно полтора года назад, после этого появился SharePoint 2013, в котором добавили очень много возможностей для использовании поиска в решениях. Но недавний опрос в сообществе (https://www.facebook.com/groups/sharepointrussian/permalink/514677285314072/?stream_ref=2) показал, что наиболее популярной версией до сих пор является SharePoint 2010.

В первой части я рассказывал как использовать стандартные веб-части поиска в SharePoint 2010, теперь расскажу как с помощью небольшого объема кода получить максимальное мощное решение для создания порталов.

DataFormWebPart

Стандартная веб-часть SharePoint позволяет использовать различные источники данных и формировать разметку с помощью XSL. Источник данных описывается с помою класса наследника System.Web.UI.DataSourceControl. В разметке страницы или .webpart файле можно указать какой DataSource использовать в веб-части.

SearchDataource

Для начала создадим DataSource, который возвращает результаты поискового запроса. На MSDN есть инструкция по созданию класса DataSource - http://msdn.microsoft.com/RU-RU/library/92e191zc(v=vs.90)

public class SearchDataSource: DataSourceControl
{
    protected override DataSourceView GetView(string viewName)
    {
        return new SearchDataSourceView(this);
    }

    public string QueryText { get; set; }

    public string SelectProperties { get; set; }        
}

class SearchDataSourceView: DataSourceView
{
    SearchDataSource dataSource;

    public SearchDataSourceView(SearchDataSource dataSource): base(dataSource,"")
    {
        this.dataSource = dataSource;
    }

    public override bool CanPage
    {
        get
        {
            return true;
        }
    }

    public override bool CanSort
    {
        get
        {
            return true;
        }
    }

    public override bool CanRetrieveTotalRowCount
    {
        get
        {
            return true;
        }
    }

    protected override System.Collections.IEnumerable ExecuteSelect(DataSourceSelectArguments arguments)
    {
        var query = GetQuery(arguments.SortExpression);

        query.StartRow = arguments.StartRowIndex;
        query.RowLimit = arguments.MaximumRows;

        var results = query.Execute()[ResultType.RelevantResults];
        arguments.TotalRowCount = results.TotalRows;
        return results.Table.DefaultView;
    }

    private KeywordQuery GetQuery(string sortExpression)
    {
        /* omited for clarity */
    }
}

Основной метод класса – ExecuteSelect, он должен возвращать IEnumerable, поддерживающий TypeDescriptor, например DataView. Про TypeDescriptors я писал ранее – http://gandjustas.blogspot.ru/2011/08/blog-post_22.html. Класс DataSourceView может поддерживать разбиение на страницы и сортировку, это определяется свойствами, которые я переопределил в начале.

Код создания запроса:

private KeywordQuery GetQuery(string sortExpression)
{
    var query = new KeywordQuery(SPContext.Current.Site);
    query.QueryText = this.dataSource.QueryText;
    query.ResultTypes = ResultType.RelevantResults;

    if (!string.IsNullOrEmpty(this.dataSource.SelectProperties))
    {
        query.SelectProperties.Clear();
        foreach (var property in this.dataSource.SelectProperties.Split(','))
        {
            query.SelectProperties.Add(property.Trim());
        }
    }

    if (!string.IsNullOrEmpty(sortExpression))
    {
        query.SortList.Clear();
        foreach (var sort in sortExpression.Split(','))
        {
            if (sort.EndsWith(" DESC"))
            {
                query.SortList.Add(sort.Substring(0, sort.IndexOf(" DESC")), SortDirection.Descending);
            }
            else
            {
                query.SortList.Add(sort, SortDirection.Ascending);
            }
        }
    }

    return query;
}

Этот код заполняет базовые параметры, запрашиваемые свойства и параметры сортировки.

Настройка веб-части

Добавляем веб-часть на страницу

Далее заменяем DataSource и вставляем identity transform

Директиву Register нужно вставлять прямо в раздел DataSource. В XSL надо вставить Identity Transform, чтобы получить данные в виде XML :

<xsl:stylesheet version="1.0"  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output indent="yes"/>
    <xsl:template match="/"  >
        <xmp>
            <xsl:copy-of select="." />
        </xmp>
    </xsl:template>
</xsl:stylesheet>

В результате получим такое:

Далее можно скопировать полученный XML и сделать необходимый XSL в Visual Studio или в SharePoint Designer.

Например так:

Создаем пакет решения

Чтобы завернуть полученный результат в WSP надо экспортировать веб-часть с сайта. Получившийся .webpart файл включить в решение. Это все.

Причем можно деплоить сборку с DataSource в farm solution, а .webpart файлы в sandbox.

Для конкретных задач можно расширить функционал:

• Добавить обработку параметров DataSource. Параметры позволяют использовать значения QueryString, связи между веб-частями и другие внешние факторы. Также можно создавать свои параметры.
• Сделать аналогичный DataSource для RefinementResults, чтобы получать статистику. Что очень часто нужно для главной страницы порталов.

Если вам нужна веб-часть в одном экземпляре (что бывает чуть менее, чем всегда), то можно не париться с сохранением .webpart и ковырянием в SharePoint Designer. Достаточно просто сделать наследника DataFormWebPart и переопределить метод GetDataSouce. При этом можно также переопределить XSL, чтобы он всегда указывал на файл в виртуальной файловой системе. Это значительно облегчит сопровождение решения.

Заключение

Как обычно исходники можно найти на http://spsamples.codeplex.com. Также сделал релиз: https://spsamples.codeplex.com/releases/view/117762.

Качайте, смотрите, изучайте, интегрируйте в свои решения.

Для тех кто не в курсе что такое SPCAF. SPCAF – аббревиатура SharePoint Code Analysis Framework, инструмент позволяющий проводить проверки кода решений SharePoint и собирать полезные метрики. SPCAF состоит из четырех компонент: SPCop, SPMetrics, SPInventory, SPDependency. Первый компонент распространяется отдельно и бесплатно. Весь SPCAF стоит 2500 евро (очень дорого).
SPCAF создавался для крупных компаний, которые работают с кучей подрядчиков, и для них очень актуальна проблема стабильности фермы в таких условиях. Проблемы, с которыми программисты сталкиваются во время разработки, в базовом наборе правил SPCop адресованы очень слабо.
Поэтому мы решили создать набор правил для SPCop, чтобы облегчить процесс разработки решений и ловить многие проблемы до того, как они проявятся во время тестирования или промышленной эксплуатации. Также создали правила, которые подсказывают best pratices при разработке решений.
Кстати мы это:

• +Станислав Выщепан (я)
• +Dmitry Dolotovskikh 
• +Anton Vishnyakov 
• +Алексей Большаков 

Как использовать

1. Поставить SPCop из галереи расширений Visual Studio

2. Скачать spcafcontrib.dll и положить в папку C:\Program Files (x86)\SPCOPCE\
3. Запустить анализ в Visual Studio

4. Анализируйте результаты и настраивайте правила

Заключение

Сайт SPCAF - http://www.spcaf.com/
Ссылка на сайт проекта - http://spcafcontrib.codeplex.com/
Презентация - http://www.slideshare.net/gandjustas/sharepoint-code-quality
Ставьте, используйте, оставляйте feedback на сайте проекта.

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

Занимаясь разработкой правил анализа кода для SPCAF (http://spcaf.com), я нашел способ как быстро исправить такую ситуацию.

Найдите все блоки кода такого вида:

try
{
    //код
}
catch(Exception e)
{
    //здесь что угодно, кроме throw;
}

Впишите throw; в блок catch. Важно что в catch указывается базовый Exception, а не конкретный тип исключения.
Ваше приложение начнет падать и вам надо будет исправить все найденные ошибки, не убирая throw. Я такое уже проделывал много раз на разных проектах, и это давало очень положительных результат. Даже если программисты будут сопротивляться, не допускайте убирания throw.

Исследование

Для тестирования правил я собрал около 70 .wsp файлов, решений SharePoint. Большинство из них — проекты, в которых мне довелось участвовать, и я прекрасно знаю все проблемы, которые возникали при разработке. Я посчитал плотность блоков try\catch без throw и вот что получилось:

• Самое проблемное решение — 1 блок на 36 строк. То есть почти каждый значимый метод был завернут в такойtry\catch.
• Решения средней паршивости — 1 блок на 90-100 строк. В некоторых из этих решений уже были проведены чисткиtry\catch.
• Хорошие решения — 1 блок на 120-130 строк. С ними никогда не возникало проблем.

Обоснование

Перехват всех исключений не рекомендуется практически всегда, на него ругается Visual Studio Code Analysis, об этом написано в Framework Design Guidelines. В книге Pragamtic Programmer, которую стоит прочитать всем без исключения программистам, коротко и емко сформулировано правило — Crash, don't Trash.
Фактически перехват всех исключений это попытка подавить ошибку, допущенную программистом. Ошибка все равно вылезает, но не так очевидно и, зачастую, в совершенно другом месте. Это и создает проблемы при разработке решений. Особенно сильно это проявляется для SharePoint, так как его API крайне сложен.
Я знаю только один случай в решениях SharePoint когда оправдано ловить все исключения и не выбрасывать их дальше — в визуальных компонентах, чтобы ошибка разработчика не завалила портал. Но даже в них стоит рассмотреть обработку конкретных типов исключений, вместо перехвата всех подряд. В остальных случаях код должен падать максимально быстро и громко, желательно сообщая о том, что пошло не так. Не надо делать никаких возвратов false или null в случае исключения, пусть код упадет, тогда разработчики и тестеры увидят ошибку, до того как её увидит пользователь.

 

Заключение

Проблема подавления ошибок актуальна не только для SharePoint решений и не только на языке C# и платформе .NET. Возможно и в других проектах вы сможете значительно улучшить ситуацию убирая подавление исключений.
PS. Набор правил, которым проверял решения — http://spcafcontrib.codeplex.com/

К декабрю 2014 года Минэкономразвития внесет в правительство законопроект об отмене для коммерческих компаний такого атрибута, как печать. Поправки коснутся только ООО и акционерных обществ. – эту новость 17 января растиражировали все СМИ.

Законодатели покусились на святое, на основу основ бюрократии — на синюю печать! Настоящий документ обязательно должен быть с печатью, с синей, круглой, чтобы оттиск был четкий и красивый. И чтоб на документе были буквы М.П. – а то ведь вдруг кто не знает, куда надо шлёпнуть оную печать.

Внезапно

На самом деле все очень просто, все дело в «майских указах»: России нужно попасть в двадцатку в рейтинге Doing Business от Всемирного банка (сейчас — 92-е место). Любое сокращение бюрократических процедур, даже на один день, может дать выигрыш в несколько позиций. Вот поэтому и решили пожертвовать печатями ради ускорения процесса регистрации юридических лиц.

Как отмена печатей повлияет на рынок СЭД

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

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

И, конечно же, необходимость иметь множество ЭЦП — для банка, для налоговой, для торговой площадки, для госуслуг – это сущий ад. Уж лучше иметь одну круглую печать! Поэтому совершенно не разделяю оптимизма коллег в этом вопросе.

Возрастут ли риски подделки документов?

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

О чем реально стоит подумать – так это о том, как сделать использование ЭЦП удобным и понятным для людей, не знакомых с основами криптографии. Здесь в качестве примера сошлюсь на решение EDSIGN, которое делает процесс подписания электронного документа таким же наглядным, как и бумажного. Кроме того, EDSIGN позволяет накладывать на документ несколько подписей (что мы и и проделываем в обычной жизни). Например, подписание многосторонних документов. Или вот менее очевидная ситуация: руководитель подписывает приказ, а потом приказ регистрируется и при этом в документ фактически нужно внести изменения — добавить номер и дату – не нарушив его целостности. EDSIGN позволяет проделывать такие вещи.

В заключение

Сама по себе отмена печатей нисколько не продвинет нас в электронном документообороте.

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

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

Проблема

Многие проекты SharePoint фактически ведутся по процессам разработки программного обеспечения. Все процессы разработки ставят целью разработку нового или доработку существующего ПО. Основные KPI для такого проекта – сроки, функциональный объем и бюджет. Еще говорят о качестве, но качество померить сложно и оно как-то выпадает из основных характеристик.

Негативным эффектом такого способа ведения проектов становится то, что создается много кастомного кода. Ведь нельзя делать разработку, когда нечего положить в систему контроля версий. Обучая разработчиков out-of-the-box функционал, я много раз слышал вопрос о том, что же будет в итоге лежать TFS.

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

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

Как добиться успеха

В первую очередь надо фокусироваться не на поставке функционала, а на увеличении value от внедрения. Причем этот самый value надо не просто определить, а измерять. Проект считается законченным, когда достигнуты целевые показатели (KPI, связанные с value), это может случиться сразу после поставки функционала (маловероятно), а может и через год (более вероятно). План проекта должен отражать действия для достижения KPI, а не работы по созданию ПО.

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

Из этого следует второй принцип – делайте проекты маленькими. Чем меньше проект, тем быстрее можно достичь целевых KPI и тем меньше возможный убыток. Маленькие проекты проще запускать и проще убивать. Чем меньше проект, тем проще он поддается изменениям. Маленький проект гораздо проще аутсорсить, если своих ресурсов недостаточно. При этом можно увеличивать число проектов, запуская многие из них параллельно.

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

Может казаться, что это очень сильно увеличит нагрузка на менеджера. Если вам приходилось управлять двумя-тремя проектами сразу, то десять проектов может показаться адом. Но оказывается есть зубры, которые могут управлять и 50 проектами - http://www.linkedin.com/groups/How-many-projects-can-project-37888.S.210671311. Сказывается эффект масштаба – чем больше проектов, тем проще управлять каждым в отдельности.

Последнее, но самое важное тем не менее - минимизируйте объем кастом кода, особенно при работе с server-side object model. Чем больше кода, тем дороже поддержка, тем меньше шанс на успех.

Заключение

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

На днях получит вот такой коммент в обсуждении на Хабрахабре:

Государственный университет в регионе N хочет себе СЭД, пользователей на 100. Кроме СЭД хочет простенький портал, телефонную книгу, новости, календарики.
На Sharepoint Server денег тратить не хочется, да и нет необходимости — рейтинги, социальные сети, политики хранения контента не в почете у сотрудников.
Поэтому решили купить СЭД на Foundation, заплатив только за СЭД-надстройку (будем считать что лицензионные права на Foundation у них уже есть).

За 2-3 года документов скопилось около 60-80 тыс. (по всем группам). По ним нужно, в самом простейшем случае:
а) осуществлять быстрый и легко настраиваемый поиск (по конкретным атрибутам и без управляемых метаданных) по любым элементам и с учетом прав
б) быстро искать и исполнять задачи. задач при этом становится = (кол-во документов * 5)

Если знаете способ реализовать это на Foundation «изкаропки», пожалуйста, расскажите, очень интересно.

Исходный пост и обсуждение можете почитать по ссылке: http://habrahabr.ru/post/210844/#comment_7260770

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

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

Кажется, что решение на Foundation действительно выгоднее. Но на самом деле это обман.

Считаем стоимость

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

Я зашел на сайт http://www.msbuy.ru/ (не реклама, просто первый удобный калькулятор из выдачи гугла) и посчитал полный объем лицензий:

• SharePoint Server – 1 шт
• SharePoint Server Standard CAL  – 100 шт (на пользователя)
• SQL Server Standard Core – 2 шт (4 ядра) 

У меня получилось 797 182.84 рублей. Лицензии на Windows Server не считал, так как они также нужны для Foundation. Для госуниверситета цена выйдет около 80 000 рублей. SharePoint Foundation, работающий на SQL Express, обойдется фактически бесплатно.

Даже если взять самых дешевых специалистов SharePoint, то их стоимость для заказчика составит не менее $60\час. Для SharePoint Server понадобится 16 часов работ по настройке представлений, для Foundation объем работ вырастет до 80 часов.

В деньгах:

• Server – 16 часов =  $960 = 33 600 рублей.
• Foundation – 80 часов = $4 800 = 168 000 рублей.

Внезапно решение на Foundation оказалось дороже, чем на Server, даже с учетом цены лицензий последнего.

Но и это еще не все.

Совокупная стоимость владения

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

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

Обязательно стоит учитывать скрытую стоимость решений. Подробнее тут - http://gandjustas.blogspot.ru/2013/07/sharepoint.html.

С другой стороны платная версия SharePoint содержит много функционала, который можно использовать без кастомизации: поиск по внешним системам, мощные рабочие процессы согласования, совместное редактирование документов, личные узлы и удобный шаринг.  Даже если не рассматривать скидку на лицензии в 90%, как для Государственных Учебных заведений, то амортизированная стоимость лицензий на одно решение оказывается гораздо ниже. Кроме того, есть программы лицензирования, по которым цена лицензий оказывается значительно ниже.

Как продают впаривают

Тоже процитирую комментарий из обсуждения:

СЭД — это не портал. Принципы разграничения прав не по элементам, а по карточкам документов, например. То же самое и при отображении. Документ в СЭД — это же не просто элемент в списке или библиотеке, это элемент, связанный с кучей всего, вроде связанных файлов, других документов, журналов, поручений (которые еще связаны с задачами). Принципы работы довольно сильно отличаются. XXX for Sharepoint нужны как раз для адаптации Sharepoint к российскому документообороту, чего из коробки никак не сделать.

Мне, как техническому специалисту, это кажется смешным. В SharePoint Standard есть наборы документов, которые позволяют связывать несколько документов в одно целое, для связанных журналов и поручений нужно делать отдельные папки в списках, чтобы можно было давать доступ сразу на группу элементов. Всю автоматизацию моно сделать в workflow или с помощью небольших кусков кода. Это абсолютно не требует баз данных, custom service application и подобных “тяжелых” кастомизаций.

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

Заключение

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

Я понимаю, что есть и хорошие решения на Foundation, которые действительно делают что-то, что не умеет SharePoint Standard или Enterprise. Но таких решений очень мало, особенно на Российском рынке. А также вам надо удостовериться, что они идеально вам подходят, ибо доработка будет дорогая.

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

Враг не дремлет!

Аналитики от ИБ регулярно сообщают нам о росте числа мобильных угроз. Это и знакомые нам вирусы, которые нашли себе питательную среду особенно на платформе Android (на iOS с вирусная опасность пока существенно меньше); и «зловреды» - malware, шпионское ПО, имеющее своей целью кражу конфиденциальных данных. И самое банальное – кража и взлом мобильных устройств.

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

Поскольку мобильные СЭД являются одним из стимулов все более широкого использования планшетов среди руководителей, нам никак нельзя игнорировать вопросы безопасности, надеясь только на специалистов по ИБ – лучше решать эту задачу сообща.

Против взлома есть приемы

Прежде всего, нужно использовать MDM – Mobile Device Management, систему для управления корпоративными мобильными устройствами, чтобы контролировать отсутствие взлома (джейлбрейк), установку потенциально опасных приложений, и в случае утраты устройства дать команду на уничтожение данных — если кто-то попытается подключиться с него к Интернету.

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

Новый взгляд на периметр безопасности

Комментирует Артем Андреев, главный специалист по мобильным приложениям ЭОС:
Точнее будет сказать, что сегодня корпоративный периметр приобретает более размытые границы. На разные приложения могут распространяться разные правила политики безопасности информации, соответственно через одни приложения сотрудники могут работать где угодно, даже находясь в командировке в другой стране, в тоже время в других приложениях сотрудники смогут работать только в рамках, например, корпоративного wi-fi.

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

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

• Уведомление отдела безопасности и/или пользователя приложения;




• Автоматическая блокировки приложения;




• Удаление информации;




• Блокировка канала обмена информацией между приложением и сервером;




• Признание всех действий человека, нарушившего правила безопасности, недействительными или временно заблокированными;




• и другие правила и их комбинации.

Шифрование канала связи

Допустим, само мобильное устройство у нас в относительной безопасности. Но взаимодействие с сервером все равно происходит по недоверенным каналам связи, например, из кофейни Старбакс или из точки доступа в аэропорту. Поставщик услуг связи публичного доступа никакой безопасности не обещает и обычно честно предупреждает об этом — есть риск, что хакеры перехватят ваш трафик.

Как минимум, мобильное приложение должно использовать SSL-шифрование, чтобы обезопасить передачу конфиденциальных данных. Если вам нужна более надежная защита, то лучше работать через корпоративную VPN. В принципе, это уже не часть СЭД, но в рамках реализации проекта такое требование может быть учтено и VPN-клиент будет установлен на все iPad, с которых осуществляется доступ в корпоративную сеть.

Мобильная ЭЦП

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

Разумеется, для этого нужна мобильная ЭЦП. Поскольку хранить сертификат электронной подписи на самом устройстве – это риск и дурной тон, а USB-ключ или (боже упаси) дискету в iPad не вставишь, в качестве носителя ключа можно использовать смарт-карту — портативный ридер подключется к порту iOS-планшета или другого мобильного устройства.

Говорит Артем Андреев, ЭОС:
При этом ЭЦП для iPad может быть одним ключом как для iEOS, так и для СЭД на PC. MicroUSB на карт-ридере позволяет подключать считыватель к PC через USB кабель. Соответственно у пользователя есть возможность использовать как два ключа (на EToken и на smart-карте), так и только smart-карту (для iPad и PC). Единственное в первом случае необходимо считать в рамках СЭД оба сертификата верными (исключительно организационные аспект). Так приложение iEOS 2 от компании ЭОС использует внешний карт-ридер и smart-карту, что позволяет пользователями выбирать наиболее комфортный формат работы. В то же время помимо iEOS2 линейка мобильных решений ЭОС включает в себя также «АРМ Руководителя» для Windows 7 и «АРМ Руководителя» для Windows 8. Для обеспечения безопасности в них используется система криптографического обеспечения КАРМА собственной разработки, позволяющая работать практически с любыми отечественными и зарубежными криптопровайдерами.

Контейнеризация — основной тренд в мобильной безопасности

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

Контейнеризация дает более широкие возможности для интеграции: если обычные мобильные приложения в iOS изолированы друг от друга и вся интеграция возможна только на уровне серверов (что менее быстро и более накладно), то внутри одного контейнера приложения могут обмениваться данными и активно взаимодействовать — это работает быстрее и позволяет реализовать более сложные сценарии интеграции.

И еще один плюс этого решения: обычный MDM порой накладывает очень жесткие ограничения на режим использования мобильного устройства – пользователю запрещается ставить многие приложения, особенно игры и социальные приложения, использовать камеру и т. д, если он хочет работать с конфиденциальной корпоративной информацией. Учитывая популярность концепции BYOD, использования личных устройств в бизнесе, такие ограничения могут оттолкнуть пользователей и те начнут требовать, чтобы компания предоставила им планшет или смартфон для работы.

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

Курс на EMM – Enterprise mobility management

По мере повышения зрелости мобильных технологии, рынок движется от частных решений отдельных вопросов безопасности к более общим платформенным решениям. Так, технологии MDM, MEAP, MES и прочие решения для мобильности объединяются в комплексные EMM-системы.

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

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

Бытует мнение, что на для построения масштабируемого ECM решения на SharePoint  требуется глубокая кастомизация и без нее никуда. Причин этому много: широко известные Large List Threshold, тормознутые разрешения, Security Scopes Limit, довольно слабые возможности создания связей между элементами, ненадежный и невыразительный движок Workflow.

Тем не менее, при правильном подходе, можно построить ECM систему, хранящую терабайты документов, без тяжелой разработки.

Принципы

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

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

Первый принцип ECM в SharePoint, который обязательно нужно применять с самого начала – разделять оперативные и архивные документы. Обычно объем оперативных документов составляет не более 20% от общего объема и со временем этот показатель уменьшается. Если в РСУБД архивность - это не более чем атрибут, то в SharePoint надо явно задавать политики, по которым документы будут перемещаться в архив.

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

Второй принцип ECM в SharePoint – использовать возможности поиска для построения выборок “всех” документов. “Всех” специально взял в кавычки, так как обычно нужны не все документы, а некоторая выборка по критериям. Для базовой реализации хватает встроенных возможностей SharePoint, сложные вещи потребуют разработки веб-частей, которые будут строить сложные поисковые запросы.

Третий принцип ECM в SharePoint, самый сложный для применения – не пытаться создать универсальную модель сущностей и связей для всего ECM, а сконцентрироваться на автоматизации конкретных процессов. Люди с аналитическим складом ума всегда пытаются обобщить механизмы работы системы, чтобы уменьшить её когнитивную сложность. Это, в свою очередь, ведет к усложнению реализации из-за частных случаев и процессов выбивающихся из общей картины. Нужно понять, что пользователям не придется сталкиваться со всей системой разом, они будут работать с малой частью системы в один момент времени. Для начала нужно исключить из лексикона слова “любой” и “все”, всегда рассматривать конкретные процессы и типы документов.

Инфраструктура

Когда разобрались с принципами нужно правильно подготовить инфраструктуру к реализации системы. Если вы еще не перешли на SharePoint 2013, то самое время это сделать. Также вам понадобится Exchange для электронной почты.

Для работы вам обязательно понадобятся четыре службы:

• Служба поиска
• Служба управляемых метаданных
• Служба профилей пользователей (должен быть настроен импорт из AD)
• Служба управления приложениями (App Management Service)

Эти службы должны работать и быть правильно настроенными, чтобы все возможности были доступны.

Обязательно нужно поставить и подключить к SharePoint серверы Workflow Manager и Office Web Apps.

На ферме SharePoint обязательно надо настроить исходящую и входящую электронную почту, а также создание групп рассылки в AD, чтобы можно было отправлять почту группам

• http://onlinecoder.blogspot.ru/2013/03/create-e-mail-distribution-group.html – краткая инструкция
• http://lambertqin.wordpress.com/2010/01/20/how-to-configure-incoming-e-mail-in-sharepoint-server-2007-with-exchange-server-2007-part-2/ – необходимые права

Далее вам понадобится как минимум три коллекции сайтов (не считая коллекции сайтов портала, MySiteHost и App Catalog):

• ECM Control Center – коллекция сайтов с включенными фичами Content Type Syndication Hub и Document ID. Шаблон может быть любой. В службе управляемых метаданных необходимо вписать url этой коллекции в поле Content Type Hub (подробнее - http://www.wictorwilen.se/Post/Plan-your-SharePoint-2010-Content-Type-Hub-carefully.aspx)
• Архив – коллекция сайтов из шаблона Центр Записей (Records Center). Архив желательно разместить в отдельной БД и настроить Remote Blob Storage.
• Коллекция сайтов с оперативными документами. В зависимости от информационной архитектуры фермы может быть несколько таких коллекций. Рекомендую сразу включить и настроить фичу Document ID в этих коллекциях.

В настройках фермы создайте подключение для отправки документов (Send To Connection) и укажите в качестве назначения урл организатора контента в коллекции узлов архива (Подробности тут: http://office.microsoft.com/en-gb/office365-sharepoint-online-enterprise-help/configure-send-to-connections-for-records-management-HA102895194.aspx).

Кстати это все доступно и в Office 365, вам необходимо будет только создать коллекции сайтов архива и оперативных документов. Для content type hub автоматически создается коллекция узлов, не видимая в списке в панели администрирования.

Схема данных

Когда ферма готова надо начинать описывать типы контента документов. Все типы контента необходимо создавать в ECM Control Center. После создания типы контента необходимо опубликовать и механизмом синдикации эти типы будут копироваться в остальные коллекции сайтов вместе с полями, формами, шаблонами документов и политиками.

Надо учитывать, что lookup поля не поддерживаются при синдикации, поэтому все лукапы надо заменить на поля выбора, поля метаданных или ссылки на DocID (придется сделать custom renderer).

Рабочие процессы

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

Процессы  могут быть двух видов:

• Структурированные – когда есть схема и четко прописаны роли.
• Ad-hoc процессы – когда набор участников задается при запуске процесса, а маршрут заранее не определен или определен частично.

Для Ad-hoc процессов удобно использовать встроенные в SharePoint рабочие процессы утверждения и сбора отзывов. Важно следить чтобы ad-hoc процессы работали в рамках небольшой группы людей, иначе процессы будут очень сильно буксовать.

Структурированные процессы могут затрагивать людей из разных подразделений и выполняться довольно долго, а также содержать нетривиальную логику ветвления. Для таких процессов имеет смысл использовать workflow в режиме SharePoint 2013, созданные в SharePoint Designer и, возможно, допиленные в Visual Studio.

Для структурированных процессов необходимо создать группы SharePoint под каждую роль в процессе. Это сильно упростит вопросы замещения отсутствующих пользователей и делегирование обязанностей (достаточно будет добавить человека в группу).

Для каждого процесса необходимо создать свой список с нужным типом контента и цеплять рабочие процессы к этому списку. Для каждой группы процессов, сходных по целям, создавайте отдельный сайт. Например для согласования договоров отдельный сайт, с несколькими списками: договоры с подрядчиками, договоры с клиентами; для командировок свой сайт, и так далее. Landing page сайтов наполните инструкциями о том, как работать с процессами. Желательно запишите видео.

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

Важно везде использовать ссылку на Document ID, вместо url файла.

Архивирование

Так как большая часть списков и библиотек в оперативных коллекциях сайтов будут иметь плоскую структуру, то они быстро превратятся в помойку. Надо настроить автоматическое архивирование с помощью политик жизненного цикла (retention policy). Их можно цеплять как к типам контента, так и к библиотекам или папкам. Например можно назначить политику – перемещать в архив документы через месяц (неделю, год, на ваше усмотрение) с даты последнего изменения. (подробнее тут - http://www.c-sharpcorner.com/uploadfile/anavijai/retention-policy-for-a-document-library-in-sharepoint-2010/). Кроме того операцию перемещения в архив можно добавить в виде действия рабочего процесса.

В Архиве необходимо настроить Content Organizer, чтобы он размещал документы по папкам. Content Organizer умеет раскладывать документы по подпапкам в зависимости от атрибутов типа контента, а также умеет создавать подпапки при достижении границы количества элементов (чтобы исключить Large List Threshold).

Еще одна возможность, которой обязательно надо пользоваться – “объявление записью”. По сути это полная блокировка изменения документа. В архиве можно настроить автоматическое объявление записью всех попадающих в него документов.

Поисковые представления

В SharePoint 2013 колонки сайта автоматически превращаются в managed properties поиска. Но, увы, без атрибута refinable. Поэтому для начала вам надо будет создать в схеме поиска нужные managed properties. Также удобно создать типы результатов (Search Result Type) под каждый тип документа.

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

Заключение

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

Чтобы упростить жизнь разработчику клиентских компонентов я написал REST веб-сервис для SharePoint 2010.

Реализация

За основу взял метод, который описывал ранее - Javascript-enabled SharePoint WCF services.

Контракт у сервиса очень простой:

[ServiceContract]
public interface ISearch
{
    [OperationContract]
    [WebGet(Bodystyle="WebMessageBodyStyle.Bare," RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)]
    Stream Query(string q, int top, int skip, string select, string orderBy, bool includeRefiners, string refiners);
}

Параметры вызова:

• q – текст запроса (обязательно).
• top – количество результатов.
• skip – с какой позиции в выборке отдавать результаты.
• select – через запятую названия managed properties в результатах.
• orderBy – через запятую названия managed properties по которым сортировать результат, после имени можно указать desc для сортировки по убыванию.
• includeRefiners – true или false, возвращать результаты уточнений или нет.
• refiners - через запятую названия managed properties для формирования уточнений.

Реализация:

public System.IO.Stream Query(string q, int top, int skip, string select, string orderBy,
                    bool includeRefiners, string r) 
{
    using (new SPMonitoredScope("Execute Query Method"))
    {
        var site = SPContext.Current.Site;
        var result = GetSearchResults(site, q, top, skip, select, orderBy, includeRefiners, r);
        return ToJson(result);
    }
}

Метод GetSearchResults довольно простой, он передает параметры запроса в объект KeywordQuery и получает результат.

private static ResultTableCollection GetSearchResults(SPSite site, string q, int top, int skip, string select, string orderBy, bool includeRefiners, string r)
{
    var query = new KeywordQuery(site);
    query.QueryText = q;
    query.StartRow = skip;
    if (top > 0)
    {
        query.RowLimit = top;
    }

    FillSelectProperties(select, query);

    FillSortList(orderBy, query);

    query.ResultTypes = ResultType.RelevantResults;
    if (includeRefiners)
    {
        query.ResultTypes |= ResultType.RefinementResults;
        query.Refiners = r;
    }
    return query.Execute();
}

Методы FillSelectProperties и FillSortList парсят значения из строки запроса и заполняют свойства объекта KeywordQuery.

private static void FillSortList(string orderBy, KeywordQuery query)
{
    if (!string.IsNullOrEmpty(orderBy))
    {
        var orderByParts = orderBy.Split(new[] { ',' }, System.StringSplitOptions.RemoveEmptyEntries);
        query.SortList.Clear();
        foreach (var part in orderByParts)
        {
            var pair = part.Split(' ');
            if (pair.Length > 1 && string.Compare(pair[1], "desc", System.StringComparison.OrdinalIgnoreCase) == 0)
            {
                query.SortList.Add(pair[0], SortDirection.Descending);
            }
            else
            {
                query.SortList.Add(pair[0], SortDirection.Ascending);
            }
        }
    }
}

private static void FillSelectProperties(string select, KeywordQuery query)
{
    if (!string.IsNullOrEmpty(select))
    {
        var properties = select.Split(new[] { ',' }, System.StringSplitOptions.RemoveEmptyEntries);
        query.SelectProperties.Clear();
        query.SelectProperties.AddRange(properties);
    }
}

Теперь самая интересная часть – преобразование результатов в JSON. Для сериализации не подойдет стандартный DataContractJsonSerializer, он не умеет сериализовывать DataSet и DataTable в компактном виде. Со времен появления ASP.NET Ajax в библиотеке появился класс JavaScriptSerializer. Он не очень быстр, зато его легко расширять, чтобы получать ровно ту разметку, которая нужна и не требуется дополнительных библиотек.

Метод ToJson:

private static Stream ToJson(ResultTableCollection value)
{
    JavaScriptSerializer ser = new JavaScriptSerializer();

    List<JavaScriptConverter> converters = new List<JavaScriptConverter>();

    converters.Add(new DataRowConverter());
    converters.Add(new ResultTableCollectionConverter());
    ser.RegisterConverters(converters);

    var resultStream = new MemoryStream();
    var writer = new StreamWriter(resultStream);
    writer.Write(ser.Serialize(value));

    writer.Flush();
    resultStream.Position = 0;

    return resultStream;
}

Для сериализации используется два дополнительных конвертера.

internal class ResultTableCollectionConverter : JavaScriptConverter
{
    public override IEnumerable<Type> SupportedTypes
    {
        get { return new Type[] { typeof(ResultTableCollection) }; }
    }

    public override object Deserialize(IDictionary<string, object> dictionary, Type type,
                                       JavaScriptSerializer serializer)
    {
        throw new NotImplementedException();
    }

    public override IDictionary<string, object> Serialize(object obj, JavaScriptSerializer serializer)
    {
        var resultTableCollection = obj as ResultTableCollection;
        Dictionary<string, object> propValues = new Dictionary<string, object>();

        if (resultTableCollection != null)
        {
            if (resultTableCollection.Exists(ResultType.RelevantResults))
            {
                var resultTable = resultTableCollection[ResultType.RelevantResults];
                propValues.Add("TotalResults", resultTable.TotalRows);
                propValues.Add("Results", resultTable.Table.Rows.OfType<DataRow>());
            }
            if (resultTableCollection.Exists(ResultType.RefinementResults))
            {
                var refinersTable = resultTableCollection[ResultType.RefinementResults];
                propValues.Add("TotalRefiners", refinersTable.TotalRows);
                propValues.Add("Refiners", refinersTable.Table.Rows.OfType<DataRow>());
            }
        }

        return propValues;
    }
}

DataRowConverter:

internal class DataRowConverter : JavaScriptConverter
{
    public override IEnumerable<Type> SupportedTypes
    {
        get { return new Type[] { typeof(DataRow) }; }
    }

    public override object Deserialize(IDictionary<string, object> dictionary, Type type,
                                       JavaScriptSerializer serializer)
    {
        throw new NotImplementedException();
    }

    public override IDictionary<string, object> Serialize(object obj, JavaScriptSerializer serializer)
    {
        DataRow dataRow = obj as DataRow;

        return dataRow != null
               ? dataRow.Table.Columns.OfType<DataColumn>().ToDictionary(c => c.ColumnName, c => dataRow[c])
               : new Dictionary<string, object>();
    }
}

Применение

Возможность делать поисковые запросы на клиенте позволяет создавать чисто клиентские веб-части, которые не требуют для работы серверного кода. Для реализации этой идеи я реализовал одну базовую веб-часть, которая работает на jQuery и jsRender, и позволяет задавать параметры и настройки на уровне .webpart файла. Таким образом одни раз установив Farm Solution с веб-сервисом и базовой веб-частью появляется возможность добавлять веб-части с клиентским кодам в виде Sandbox решений.

Пример такого решения я, как обычно, выложил на codeplex:

Исходники - https://spsamples.codeplex.com/SourceControl/latest#SearchWidgetWebParts/

Релиз - https://spsamples.codeplex.com/releases/view/118068

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

Заключение

Это последняя часть серии про использование поиска в SharePoint 2010. Часть 1 и Часть 2 по ссылкам.

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

• SharePoint Administrator Roadmap – гайд для тех, кто хочет изучать администрирование SharePoint 2010.

• SharePoint Developer Roadmap – для разработчиков SharePoint 2010.

В SharePoint 2013 появилось много новых возможностей. Теперь для разработчика недостаточно просто уметь писать веб-части и event receivers. В SharePoint 2013 поставить ферму для разработки – само по себе требует многих навыков, а разработчику надо еще как минимум уметь настраивать поиск, управляемые метаданные, профили пользователей, apps и workflow.

Чистая разработка для SharePoint 2013 идет в сторону apps (ASP.NET), но закрывает лишь малую часть потребностей заказчиков. Навыки развертывания, администрирования и использования стандартного функционала оказываются для разработчиков чуть ли не важнее навыков писать код.

Поэтому я не буду разделять курсы для разработчиков и администраторов. Для профессионалов, создающих решения на SharePoint, они одинаково важны.

Далее ссылки на курсы и каталоги материалов, которые можно использовать для самостоятельного изучения:

1.  http://technet.microsoft.com/en-US/sharepoint/fp123606 - SharePoint 2013 training for IT pros.
2. http://msdn.microsoft.com/en-US/office/dn448488 - Office 2013 developer training videos. Пусть не пугает называние, большая часть курса – по SharePoint 2013.
3. http://www.microsoft.com/resources/Technet/en-us/Office/media/ITProPivotViewer/ – интерактивный браузер всего контента Technet.
4. http://technet.microsoft.com/en-US/projectserver/jj906608 - Project 2013 training for IT pros and developers.
5. https://channel9.msdn.com/Events/SharePoint-Conference/2012 – видео с конференции SharePoint Conference 2012, в докладах часто можно встретить темы, отсутствующие в документации.
6. http://pluralsight.com/training/Courses#sharepoint – Pluralsight, крайне рекомендую. За $300 в год (меньше цены одного курса в УЦ) вы получите 99 (на сегодня) и более (в будущем) курсов по SharePoint 2007-2013. Некоторые из них содержат уникальный контент, который более нигде не доступен.
7. http://www.microsoftvirtualacademy.com/Studies/SearchResult.aspx?q=SharePoint – курсы на Microsoft Virtual Academy, есть очень полезные курсы с глубоким погружением в тему.
8. http://code.msdn.microsoft.com/officeapps/Apps-for-SharePoint-sample-64c80184 - Примеры приложений для SharePoint, увы, код не всегда рабочий.
9. http://social.technet.microsoft.com/wiki/contents/articles/14579.sharepoint-2013-books-a-comprehensive-list.aspx – список книг по SharePoint 2013, но если вы изучите все по ссылкам выше, то вам надо будет только прочитать Inside SharePoint 2013.
10. http://spf2013faq.mindsharp.com/Lists/SharePoint%202013%20Books%20and%20Extracts/V%20Books.aspx – тоже список книг.

Для начала хватит. Как обычно нужно много и внимательно читать MSDN и TechNet.

Изучайте, пользуйтесь, создавайте хорошие решения.

Комбинирование известных вещей часто дает новое качество, это один из основных приемов изобретательской деятельности. Что будет, если совместить BPM и аналитику?

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

Есть еще один вариант совместного использования этих технологий — Process Mining или еще говорят Process Intelligence, когда средствами аналитической системы из логов разных бизнес-приложений, из статистики выполнения экземпляров процессов, вытаскивают информацию о реальных маршрутах, которую затем используют при моделировании «правильных» процессов. Это как сначала дать людям протоптать тропинки по газонам, а потом их заасфальтировать вместо того, чтобы придумывать абстрактную планировку. Хороший метод, но с одним минусом — это анализ вчерашней информации в интересах завтрашнего дня. В одних областях, где процессы постоянны, это работает. В других, где царит изменчивость и неопределенность — не очень.

IBO – аналитика внутри бизнес-процесса

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

Чтобы соответствовать тренду IBO, Intelligent Business Operations, системы управления бизнес-процессами, BPMS, должны будут трансформироваться в iBPMS – интеллектуальные BPMS. Речь идет не только о встраивании BI в BPM; разумеется, не обойтись без социальности и мобильности, эти технологии тоже нужны – чтобы дать бизнес-системам возможность реагировать на события внешней среды более гибко, разумно и адаптивно. (Уже практически по Дарвину.)

Например, поставщик питания на спортивном мероприятии (хоть на Олимпиаде), используя iBPMS может давать более интеллектуальную обратную связь болельщикам, основываясь на real-time анализе запасов провизии на одной торговой точке по сравнению с другой и оперативно перенаправлять посетителей туда, где очередь короче.

IBO и Big Data

Маркетологи своего не упустят: где бы ни сказали слово про аналитику, они тут же приплетут и Большие данные. Не вижу такой уж острой необходимости говорить именно о Big Data в данном контексте – повысить разумность ведения бизнеса можно и при помощи более простых аналитических инструментов. Просто нужные цифры должны быстро появляться в нужном месте.

IBO – это изменение модели доставки аналитики в бизнес-процесс, а не ее количества. Больше данных не всегда значит лучший анализ и принятие лучших решений. (Но там, где Big Data реально нужны — welcome!)

Основная цель IBO – не анализ сам по себе, а лучшее удовлетворение запросов клиентов. Грубо говоря, чтобы клиентов перестали посылать –

«Наша система так не может, извините»

Больше всего бесит клиентов ответ, что «наша система так не позволяет», когда клиент просит какую-то совсем простую вещь — немного изменить заказ, уточнить время доставки, оплатить разными платежными инструментами. Любое отклонение от жесткой схемы способно вызвать панику и паралич воли у обслуживающего персонала и даже у менеджеров. Все несуразности и неудобства бизнес-процесса в итоге ложатся на клиента. Но это же неправильно!

Концепция IBO предлагает смотреть на мир по другому, не так, как прежде – «у нас есть инструкции и мы по ним работаем, а там трава не расти». Новый подход гласит, что в мире происходят различные события и мы должны быть готовы быстро проанализировать ситуацию и адекватно на нее отреагировать.

IBO (и iBPMS) — это снижение жесткости систем. Иначе говоря, мы имеем подход Agile, хорошо знакомый разработчикам, применительно к бизнесу. Если мы можем создавать очень сложные системы, пользуясь этой методологией, почему бы не расширить ее на обслуживание клиентов?

Разница в одну букву, но это серьезно

Старые BPMS, заточенные под жесткие схемы работы, не позволят вам реализовать новые гибкие, умные, адаптивные процессы. С 2012 года Gartner выпускает отдельный Магический квадрат по iBPMS, и это уже признак того, что рынок новую концепцию принял – есть, что анализировать. :)

Причем, iBPMS четко дистанцируется от просто BPMS – Gartner предупреждает, что их даже не надо сравнивать.

В заключение – как концепция IBO влияет на ECM

• Придется изменить модель метаданных: сейчас она больше ориентирована на учет (комплаенс), а придется развернуть ее на аналитику. Иначе любой BI окажется беспомощным — все-таки документы приходится искать по их атрибутам, а не по тексту.




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




• Контент рулит! Или еще раз о юзабилити – людям нужны документы, а не регистрационные карточки из канцелярии. Поставщики СЭД (те, которые еще не стали ECM) упрямо норовят показать пользователю сначала карточку, а уж потом после пары таинственных пассов можно добраться до содержания. Сначала важное (содержание), потом справочные данные (карточка).

В общем и целом ECM тоже должны трансформироваться чтобы вписаться в новую динамичную концепцию IBO. Причем технически проблем особых нет – платформы сегодня достаточно гибкие, не то что наши мозги:) Тормозить процесс будет только консервативность мышления.