По следам статьи о больших данных, хотелось бы поговорить о конкретных технологиях, применяемых при реализации решений в этой области. Речь пойдет о In-Memory технологиях, а именно In-Memory Data Base (IMDB) и In-Memory Data Grid (IMDG). Если говорить русским языком, то это базы данных использующие оперативную память компьютера в качестве основного хранилища.

Немного предыстории

Почему In-Memory решения стали такими популярными? Дело в том, что стоимость оперативной памяти неуклонно падает, что позволяет хранить весь набор операционных данных непосредственно в памяти, увеличивая тем самым скорость их обработки более чем в 1000 раз. Так же важен тот факт, что современные серверные операционные системы, такие как Windows Server 2012, способны использовать до 4ТБ RAM. А объединив эти сервера в кластеры, можно получить хранилища данных с внушительным объемом и не менее внушительной скоростью доступа.

Чем отличается IMDB и IMDG?

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

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

Среди крупных игроков на этом рынке можно выделить SAP с реляционной IMDB HANA, Oracle с IMDB TimesTen, а так же IMDB от MemSQL и IMDG от GridGain.

Слабые стороны

У IMDB/IMDG как и у любой другой технологии есть свои слабые стороны, в первую очередь это стоимость. Несмотря на то, что цены на RAM стремительно падают, они по прежнему намного выше, чем у своих твердотельных аналогов. К тому же из-за особенности устройства оперативной памяти, в случае обесточивания все данные моментально исчезают, что требует от компаний вложений в дорогостоящие инфраструктурные решения, обеспечивающие бесперебойное питание и схемы регулярной репликации данных на твердые носители.

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

Области применения

Основными областями применения In-Memory решений являются:

1. Анализ данных рынка, Реакция на события (CEP), Торговля.

2. Авторизация, Online транзакции (OLTP).

3. Real-Time аналитика – интерактивное представление данных, витрины данных.

4. Электронная коммерция (Electronic Data Interchange, e-trade, e-cash, e-marketing), персонализация, Real-Time обслуживание.

В качестве интересного примера внедрения можно привести компанию Pirelli. С помощью In-Memory технологий они анализировали данные с датчиков шин, для достижения наилучшего сцепления с дорогой.

ECM?

Открытым остается вопрос о полезности In-Memory в ECM, если посмотреть на области, то в основном это ниша ERP и BI систем. Использование подобных технологий в ECM пока кажется избыточным и выглядит как стрельба из пушки по воробьям, по крайней мере, до тех пор, пока не будут найдены задачи, требующие от системы молниеносной реакции и не решающиеся простым масштабированием существующей инфраструктуры.

Недавно появилась новость о том, что Google планируют выводить свой сервис Hangouts на корпоративный рынок, как новую часть Google Apps для бизнес-пользователей.

«Мы пытается упросить процесс использования Hangouts для организации встреч внутри компаний» - сообщил Клэй Бэвор, вице-президент по продуктовому менеджменту Google Apps. Hangouts – это сервис для организации видеовстреч в реальном времени и высоком качестве с помощью персонального компьютера или Chromebox-а и поддержкой до 15 участников.

Организация видеосвязи с космической станцией через Hangouts:

«Сейчас Hangouts попадает под те же условия использования, что и другие наши приложения для бизнеса из Google Apps, такие как Gmail и Drive», - пишет Бэвор в своем блоге. «Это значит, что мы обеспечиваем работу в режиме 24x7 для мобильных устройств и гарантируем, что наши сервисы будут доступны 99.9% времени, согласно стандартам ISO27001, SSAE 16/ISAE 4302 и сертификату SOC 2. Кроме того интеграция Google Apps Vault для организаций будет завершена к концу года ». Напомню, что Google Apps Vault – это облачный сервис для хранения, архивирования и поиска переписок сотрудников организаций, с его помощью обеспечивается неприкосновенность и целостность данных, в том числе для юридических процедур.

В новости говорится, что привлечение бизнес-пользователей в Hangouts – это ещё один способ Google попасть на корпоративный рынок. Кроме того, это часть PR компании для продвижения Chromebox и веб-ОС Chrome на корпоративный рынок устройств.

Бэвор пишет: «В ближайшие месяцы мы будем адаптировать Chromebox для лучшей работы в различных по формам и размерам помещениях. В больших конференц-румах вы сможете подключить несколько дисплеев к одному Chromebox, чтобы видеть ваших собеседников и текст презентации одновременно. Кроме того, с помощью новых инструментов интеграции вы сможете легко настроить Chromebox для организации видеовстреч за пределами офиса». Он так же добавил, что системные администраторы смогут управлять видеовстречей удаленно через консоль администратора в Google Apps.

«Google активно продвигается на корпоративный рынок или, по крайней мере, пытается», - говорит аналитик Technology Business Research Эзра Готтхейл. «Изначально Hangouts был представлен как часть Google+, однако Hangouts выглядит дружелюбнее для бизнеса в качестве отдельного сервиса».

Значит ли это, что у компаний появится более демократичная альтернатива Microsoft Lync? Мы узнаем совсем скоро, Google планирует выпустить обновленную версию Hangouts уже 19ого августа этого года.

Анатолий Белайчук евангелист BPM в компании Comindware.

Во всем виноват Адам Смит! Ведь это он изобрел разделение труда. Впрочем, есть мнение, что он его не изобрел, а лишь описал. Пусть так – в конце концов, дело не в личности, а в явлении.

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

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

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

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

Первые сложности возникают, когда мы переходим от выпуска швейных иголок, рассмотренных Смитом, и легендарной модели T, «цвет которой может быть любым при условии, что этот цвет черный», к чему-то более разнообразному. Возникает неопределенность тем большая, чем шире номенклатура готовой продукции и чем через большее число переделов (читай – производственных цехов) должно пройти первичное сырье, чтобы превратиться в готовую продукцию. Западные люди привлекают на помощь компьютер и разрабатывают системы MRP, MRP-II, ERP, APS… Японцы идут своим путем и изобретают Just In Time и «аналоговый компьютер» канбан. Так или иначе, каким-то из этих методов (а скорее – их сочетанием) проблема решается.

Под многозадачностью понимается необходимость многократно в течение дня (а то и часа) переключаться с одной работы на другую. Работники производственного конвейера жалуются на монотонность работы, работа же в офисе сегодня представляет собой другую крайность: чем грамотнее, опытнее, ответственнее сотрудник, тем больше его «грузят» – тем в большем числе процессов его стремятся задействовать.

Естественных защитных реакций две: во-первых, попытаться минимизировать число переключений. Например, бухгалтерия подписывает счета только после 16 часов, потому что обрабатывать их сразу значит переключаться, а это влечет за собой «снижение производительности». Это классический пример «локальной оптимизации» (на всякий случай, слово ругательное): производительность бухгалтерии при таком подходе повысится, но эффективность компании в глазах клиента, очевидно, уменьшится.

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

Теперь что касается нешаблонности. Замерить и отнормировать производительность производственного рабочего, занятого на рутинной работе – нет проблем. Но как померять объем работы, выполненной, например, программистом – числом строк кода? Такой способ многократно заклеймен как порочный, но штука в том, что ничего лучшего, по большому счету, не придумано. И со всеми работниками умственного труда эта проблема: «он думает»! Чего он там думает и надумает ли что в итоге – непонятно, а зарплату за каждый отработанный час заплати!

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

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

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

Всякий раз, когда от функционально-иерархической организации требуется результат, который требует совместной работы нескольких подразделений, ее лихорадит. Классический пример: бизнес «Проектирование под заказ». Это когда для того, чтобы выдать потенциальному заказчику коммерческое предложение (т.е. назвать цену и сроки), требуется заинтересованное участие как минимум: 1) менеджера продаж, который держит канал коммуникаций с клиентом, 2) конструкторов-инженеров, которые должны определиться как и из чего мы это будем делать, 3) снабженцев, которые должны сказать сколько это «из чего» будет стоить, 4) производственников, которые должны сказать в какие сроки мы способны это произвести и 5) экономистов, которые должны сосчитать, во что нам это обойдется.

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

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

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

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

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

Пороговый масштаб, при достижении которого надо издержки разделения труда становятся неприемлемыми, конечно же, зависит от субъективных факторов – личности первого лица, культуры компании, ее возраста… Поэтому его нельзя определить однозначно, но думается, что для большинства организаций предел, за которым надо всерьез думать о компенсации органических дефектов функционально-иерархического управления, лежит в диапазоне от 20 до 100 сотрудников, за среднее можно взять число 50 (напомним, учитываются только «белые воротнички»).

Продолжение следует.

Как правило, при интеграции систем СЭД выполняет роль транспорта информации между участниками информационного обмена, а также роль электронного архива предприятия. Так, например, из ERP-системы можно открыть скан-образ счета или акта, находящегося в СЭД или открыть текст договора, к которому был выписан счет, при этом СЭД загружать не нужно. Таким образом, ECM-система является основным связующим звеном всех корпоративных систем.

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

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

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

Специализированные системы, имеющие мощные функции анализа, такие как BPM, CRM, нуждаются в оперативных данных, которые может предоставить ECM-системы – внутри неё фиксируется множество бизнес-процессов и сопутствующий контент. И при интеграции эти данные могут получить максимально эффективный анализ в специализированных системах.

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