ERP-системы *

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

В предыдущем посте мы попрощались с читателями до нового года, но как бы не так! Один из сотрудников нашёл в Интернете интересный вопрос, заданный пользователям форума для продажников. И у него, точнее, неё, родился возмущения пост. Как нам кажется, эмоции явно не напрасны, поскольку девушка уже восьмой год идёт рука об руку (голова об код?) с корпоративным программным обеспечением разного рода и знает, о чём говорит. В общем, передаём ей предновогодний микрофон.

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

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

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

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

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



Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!

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


Источник: stats.stackexchange.com

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



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

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

Картинка с the9gag.com

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

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

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

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

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

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

Зарегистрировавшийся пользователь после ~20 минут ожидания генерации частного облака получит доступ к развернутой инсталляции управляющей системы предприятия начального уровня Ultimate 2C.

 В созданном облаке будут развернуты:

• универсальная IEM-платформа Ultimate Solid
• базовая конфигурация Ultimate 2C
• средства разработки и кастомизации конфигурации
• демо-данные (товары, клиенты, поставщики и прочие контрагенты).
• веб-компонент интернет-магазина на базе CMS UMBRACO

Интерфейс — английский (с возможностью переключения на русский в настройках).

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

По словам вице-президента 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%. История потому и тиражируется, что пример завидный даже для первопроходцев использования данных — онлайн-ритейла. В общем, если вы можете похвастаться таким же кейсом — листайте Хабр дальше, если нет — поговорим под катом о том, как приучить себя к аналитике, научиться в любой кризис идти по приборам и наконец повзрослеть.

Стала доступна полная программа Открытого Воскресенья — дня на партнерском семинаре 1С, который может посетить (за плату) любой желающий, а не только сотрудник нашего партнера или франчайзи.

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

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

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