ERP-системы *

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

Небольшие вводные данные:

1. Проект закрытый. Разрабатывается для себя.
2. Среда разработки не имеет значения. Алгоритмы теории ограничений – простая математика, а значит, реализуются любым доступным языком программирования.
3. Все заметки – это попытка поделиться нашей практикой с миром. Теорию ищите в интернете.

Раздается звонок.

— Здравствуйте, это Сергей? Меня зовут <Ηράκλειο> (не вникайте в название, слово существующее, но это плоды секундной фантазии), я — директор по производству на <Κρήτη>. У меня есть ряд проблем с производственным планированием. Могли бы мы с вами встретиться?

На встрече присутствовал Ηράκλειο, генеральный директор и, случайно заглянувший, собственник бизнеса. Мне предоставили список технических требований к производственному планированию, наличие которого положительно сказывается как предметности разговора. В ходе беседы познакомились, поделились коммерческой и организационной информацией, очертили первые шаги.

Доработка типового программного обеспечения под требования заказчика — это обыденное дело, если оно правильно организовано. Однако часто можно встретить примеры, когда разработчики берутся выполнить работы без ТЗ (технического задания) по настоянию заказчика. Что происходит в итоге? Обе стороны загоняют себя в яму, которую выкопали сами. Разработчик не подозревает, что он будет вынужден выполнить объем работ во много раз больше предполагаемого, и рано или поздно остановит эти работы, нахлебавшись раздувшихся аппетитов заказчика, которые будут расти в геометрической прогрессии, не имея формальных ограничений. В такой ситуации разработчик рискует никогда не завершить работу, а заказчик — никогда не получить нужного результата. На ранних этапах развития компании мы в этой яме побывали неоднократно, поэтому представляем вторую часть наших историй о ТЗ — когда его нет.

По словам вице-президента Gartner Найджела Рейнера (Nigel Rayner), в течение десяти лет большая часть компаний обратит свой взор на облачные технологии. «Вместо решений on-premises, организации будут стремиться к переносу всего функционала в облако», — отмечает Найджел. Эта тенденция касается и систем планирования ресурсов предприятия (ERP) – в период с 2011 по 2016 год общемировые траты на ERP ПО увеличились на 27%.


/ фото wagdi.co.uk CC

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

Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.

О

• управлении потоком задач на разработку,
  Как избавится от «дурацких» задач?
• управлении расходами на разработку,
  Как определить и выбрать самые выгодные задачи?
• распределении ограниченных ресурсов.
  Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

Изначально CRM-системы создавались именно для продаж. Группа программного обеспечения, призванная облегчить труд продажников, получила название sales force automation (SFA) — автоматизация торгового штата. Собственно, именно от этого факта и получила своё название одна из самых старых и самых известных мировых систем — Salesforce. Но менеджмент не стоял на месте — в современных продажах клиент стал во главе угла, CRM-системы (системы управления взаимоотношениями с клиентами) стали популярнее SFA (но не равны им!). На этом месте обычно долго рассказывают о лояльности, предиктивном маркетинге и прочих пиар-штучках, но посыл гораздо проще. Что бы мы ни создавали, будь то корпоративный софт, игра, приложение или дата-центр, это нужно продать, быстро обойдя конкурентов. И у нас, программистов, это получается не очень. Точнее, не получается вообще.

Можно ли войти в одну реку дважды?

Данная статья написана по результатам доклада на конференции Нефтегазстандарт – 2016, сделанная мной от имени компании ТриниДата.

Работая инженером — онтологом, я занимаюсь созданием информационных моделей для информационных систем.

В этой статье я хочу рассказать о практике применения стандарта ИСО 15926 к моделированию активов предприятия, и о том, к каким результатам это привело нас в итоге. Те, кто незнаком со стандартом, могут не расстраиваться — чтение статьи будет полезно независимо от знания стандарта.

По интернету много лет бродит история о том, как в США интернет-магазин Target попал на гнев разъярённого отца из-за рассылки рекламы товаров для беременных в адрес несовершеннолетней школьницы.  Спустя несколько дней оказалось, что девушка действительно беременна. Тarget узнал обо всём раньше за счёт анализа больших данных. И за счёт использования этой самой системы анализа данных вырастил свою выручку в кратчайшие сроки более, чем на 60%. История потому и тиражируется, что пример завидный даже для первопроходцев использования данных — онлайн-ритейла. В общем, если вы можете похвастаться таким же кейсом — листайте Хабр дальше, если нет — поговорим под катом о том, как приучить себя к аналитике, научиться в любой кризис идти по приборам и наконец повзрослеть.

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

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

27-28 октября в Москве состоится юбилейная пятая конференция «Проектирование бизнес-архитектур 2016» — ключевое событие года для профессионалов по проектированию бизнес-архитектур и управлению бизнес-процессами. В рамках этого мероприятия ведущие эксперты расскажут о новых тенденциях, методологиях, а также поделятся best practice на примере своих проектов развития компаний.

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

/ фото Jaro Larnos CC

В нашем блоге на Хабре мы делимся с вами новостями из мира IaaS, а также рассказываем о новых технологиях и трендах. Сегодня нам бы хотелось поговорить о системах планирования ресурсов предприятий (ERP), а точнее, об их облачных реализациях. Отметим, какие тренды намечаются в сфере ERP-систем, и чем облачные системы планирования ресурсов отличаются от своих «коллег на местах».

Согласно отчету Gartner, облачные альтернативы локальным ERP-системам серьезно укрепят позиции, и к 2018 году как минимум 30% компаний, занятых в сфере предоставления услуг, переведут большинство своих ERP-приложений в облако.

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

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

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Предлагаю читателям "Хабрахабра" историю о том, как я искал удобный таск-менеджер для работы среди множества готовых решений и в итоге остановился на самописном.

Вам будет интересно почитать, если вы:

• Не довольны своим таск-менеджером, так как он очень сложный/неудобный
• Работаете с небольшой командой
• Часто взаимодействуете с коллегами через месенджеры, и вам хотелось бы иметь таск-менеджер под рукой
• Хотели бы начать знакомство с простым и понятным таск-менеджером

Решение распространяется под лицензией GNU GPL, ссылка на репозиторий будет в конце статьи.

Наверняка многие из вас видели в интернете фотогалереи с заброшенными торговыми центрами, огромными и некогда роскошными. Впечатляющее зрелище, особенно для бизнесмена. Но первая мысль вовсе не о том, сколько денег, инвестированных в развитие, пропало. Она о том, почему это произошло. Да, есть фактор влияния структурных сдвигов экономики, есть и «вина» онлайн-торговли. Но главное — это неумение вовремя перестроиться, адаптироваться, изменить бизнес-модель. Причём не отказываясь от существующей, а встраивая её в новые условия.
Та же история может случиться с проектом внедрения CRM: система простаивает, компания меняет вендора, выбирает более дорогую систему, которая снова простаивает… Замкнутый круг. А между тем, причины неудачи довольно линейны — и в ваших руках сделать внедрение CRM успешным. Делимся опытом, как.

На Гайдаровском форуме Герман Греф заявил, что Сбербанк будет переходить на новые информационные технологии, выбрав в качестве основного партнёра российско-американскую компанию с численностью 60 чел. При этом Сбербанк потратил 65 млрд. руб. на амбициозный и сложный проект централизации ИТ- структуры и на сегодняшний день у него более 22 000 ИТ-сотрудников, включая 6 тыс. человек в Сбертехе. Основная причина перехода — скорость внесения изменений в ИТ, которая была низка и привела к отставанию ИТ Сбербанка от лидеров по развитию и гибкости ИТ-инфраструктуры. А насколько важна скорость внесения изменений в разработке? На что нужно обратить внимание в управлении процессом разработки? Стоит ли использовать модели и методологии? Попробуем разобраться.

В статье ответим только на один вопрос – как мы решаем, что и когда реализовывать в платформе «1С:Предприятие».

Именно в такой формулировке нам его задают редко, но часто и даже очень часто появляются конкретные вопросы – «почему вы сделали это?», «почему вы НЕ сделали это?», «почему бы вам не сделать это?», «когда вы сделаете это?», «когда же вы, наконец, сделаете это?!!!», …

Попробуем описать то, как мы решаем, что когда делать.

Количество программ — мобильных клиентов, привязанных к различным системам автоматизации деятельности предприятий, постоянно растёт. Согласно исследованию компании IDC, к 2016 году оно увеличится в 4 раза (по сравнению с 2014 годом). Конечно, ABBYY не могла остаться в стороне от этих тенденций, и у нас есть мобильные продукты, ориентированные на корпоративных пользователей. Об одном из них – ABBYY Mobile Imaging SDK (MI SDK) – мы ещё ни разу не рассказывали в блоге, исправляемся.

Наши пользователи привыкли, что мобильные продукты ABBYY – это либо про словари, либо про распознавание. Сразу оговоримся – в ABBYY Mobile Imaging SDK нет ни того, ни другого. Спрашивается, почему нам понадобилось выпускать такое приложение? Ответ – конечно, чтобы продать OCR ещё большему числу клиентов :). Ведь ABBYY Mobile Imaging SDK обычно используется в связке с нашими «корпоративными» решениями для распознавания данных (например, ABBYY Recognition Server) или извлечения данных (например, ABBYY FlexiCapture). Этот небольшой продукт призван помочь нашим «большим» решениям работать лучше, распознавать точнее.

Жизнь изменилась, и если раньше основным устройством, с которого мы получали изображение для распознавания, был сканер, то теперь его всё чаще заменяет мобильный телефон. Чем он отличается от сканера? Конечно, тем, что получить с него изображение хорошего качества гораздо сложнее (разумеется, в данном случае хорошее качество = достаточное для того, чтобы наши OCR-технологии могли распознать текст на фото).

Современные разработчики систем автоматизации имеют богатые возможности: это многочисленные языки программирования, библиотеки, огромные репозитории открытого кода, наконец, относительно доступное практически любое оборудование, необходимое для разработки и тестирования. В 50-е годы, когда в СССР зарождалась идея создания АСУ и начала активно развиваться кибернетика, всех этих ресурсов не хватало. Учёные того времени были не только сухими прагматиками, но и мечтателями — им хотелось позитивных изменений социо-экономических отношений, которые была призвана обеспечить АСУ. Однако вся дальнейшая история создания автоматизированной системы управления в рамках командной экономики и бесконечной бюрократии не столь оптимистична. Но обо всём по порядку.

Каждый из нас периодически сдаёт кровь на анализ. В последнее время всё стало очень удобно: сдал, получил логин/пароль, через несколько часов заглянул на сайт в личный кабинет и там все показатели в числах, а рядом зелёные или красные буллиты «норма/не норма». Но мало кто знает, что даже полностью зелёный столбец или столбец с парой красных буллитов на каком-нибудь непопулярном показателе типа эозинофилов могут свидетельствовать о неполадках в организме, и только врач может верно интерпретировать картину. Почему? Потому что все показатели необходимо рассматривать в совокупности и взаимосвязи — сами по себе они несут чисто справочную информацию. Так же и в бизнесе, сложной и многоуровневой системе, необходимо выстраивать систему аналитики, которая даст комплексное понимание положения дел. Что нам стоит аналитику построить?