ERP-системы *

Привет, Хабр!

Сегодня мы смоделируем процесс разработки и поддержки актуальности пользовательских инструкций силами самих пользователей. Этот подход существенно упрощает жизнь службам, ответственным за поддержку и развитие систем. Для этого мы будем использовать 2 продукта: SAP Solution Manager и SAP Workforce Performance Builder –инструмент для разработки интерактивных инструкций для пользователей любых ИТ-систем. С первым, я уверен, большинство знакомы, а со вторым мало кто сталкивался. В первой части мы подружим эти два решения, чтобы процесс заработал, а во второй — создадим в Solution Manager программу обучения для подготовки новых сотрудников, в которой будут использоваться актуальные (всегда!) материалы, созданные в SAP WPB.

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

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

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

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



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

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

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

Мы пытаемся делать Яндекс.Почту такой, чтобы в ней всё всем сразу было очевидно и никакая помощь не была нужна. Увы, это не всегда получается, поэтому у нас есть служба поддержки. Думаю, на Хабре многие понимают, что очень непросто организовать службу поддержки так, чтобы она могла быстро отвечать всем пользователям такого огромного сервиса, как Яндекс.Почта, и при этом не рассылала полуавтоматизированные отписки, а помогала по существу и разбирала проблемы в самом сервисе.



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

Сегодня предлагаем поговорить об основных вещах и особенностях, которые нужно знать при работе с приложением Message Flow Monitoring, представленном в системе SAP Solution Manager 7.1 SP12.

Коротко о главном: что такое SAP Solution Manager
Заказчики требуют от нас четкой и понятной стратегии управления ИТ-решениями, стандартизованные процессы поддержки, а также инструмент, позволяющий их автоматизировать. Ответом стала методология Run SAP, содержащую рекомендации по эксплуатации продуктов SAP. Кроме методологической поддержки, всем своим клиентам мы бесплатно предоставляем продукт SAP Solution Manager, являющийся платформой для управления жизненным циклом приложений.

При помощи SAP Solution Manager автоматизируются все процессы, описанные в ITIL (соответствие Information Technology Infrastructure Library подтверждается независимыми сертификациями): документирование бизнес-процессов, управление инцидентами и проблемами, управление изменениями, управление тестированием и многие другие. Среди них одной из наиболее востребованных функций является технический мониторинг ИТ-решений. Он позволяет проактивно и централизованно отслеживать состояние большого количества ключевых показателей функционирования систем SAP. В его состав входят:

• мониторинг систем SAP, СУБД и серверов.
• мониторинг интеграционной шины (PI мониторинг) и интерфейсов
• мониторинг фоновых заданий
• мониторинг решений с точки зрения конечных пользователей.

В рамках этой статьи мы рассмотри приложение Message Flow Monitoring, которое дополняет возможности уже существующего PI мониторинга, позволяя выполнить централизованный анализ выбранных бизнес-критичных потоков сообщений из системы SAP Solution Manager. Оно оценивает прохождение информации через весь PI ландшафт на уровне каждого, отдельно взятого сообщения.

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

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

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

Привет, хабрасообщество!

В данной статье я хотел бы осветить новые подходы к разработке на ABAP, применительно к SAP HANA. Мы рассмотрим новые элементы языка ABAP, которые позволят эффективнее использовать возможности, предоставляемые SAP HANA.

Допустим, у нас есть отчет, написанный на языке ABAP, время работы которого нас не устраивает. Мы хотим оптимизировать работу этого отчета. Основная идея изменения логики работы отчета, заключается в том, что часть логики отчета, которая интенсивно использует данные из СУБД (в нашем случае это SAP HANA), будет делегирована на уровень СУБД.


Рис.1. Code to Data pushdown.

Для осуществления этого подхода могут быть использованы следующие конструкции:

1. Расширенный Open SQL
2. FOR ALL ENTRIES
3. ABAP Managed Database Procedures

Сегодня немного философии про архитектуру программных систем — монолитной или модульной. Когда и какая модульность полезна, всегда ли она благо или нет. Ну и более предметно про ERP системы как близкая нам тема.

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

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

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

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

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



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

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

Вступительное слово

Сегодня очень модно стало автоматизировать бизнес. Повальная информатизация — модное явление. Чаще всего руководители самих компаний, которым продали данные услуги, просто не понимают, что именно они покупают. В их голове любая CRM-система становится некоей волшебной кнопкой, которая решает их организационные проблемы. Что это значит?

Есть предприятие, которое мы назовем «Рога и Копыта», руководитель которой услышал от своих коллег-предпринимателей о том, как стало лучше работать, когда в компании стала использоваться новая CRM-программа. Интеграторы взяли не так дорого, проект обошелся дешевле, чем SAP или «1С: УПП». Что делает человек под давлением общественного мнения? Повторяет!

Если у вас появилась мысль «а не запустить ли на моем предприятии проект для того, чтобы автоматизировать бизнес?» — данная публикация для вас.

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

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

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

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

Итак, в крупном производственном холдинге есть много компаний, объединённых в одну группу. В 2011 и 2012 году они показывали высокую прибыль, при которой можно забыть об оптимизации и просто фигачить как можно быстрее дальше, пока получается. «Что тут думать, трясти надо» — оптимальная бизнес-стратегия на таких нормах прибыли. В 2013-м году из-за общей экономической ситуации стало понятно, что прибыль будет снижаться. Соответственно, первое, что начало делать большое руководство — это разбираться, куда и как конкретно тратятся деньги, чтобы найти то, что можно безболезненно оптимизировать или просто убрать.

Добрый день!

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

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