• Олды в ИТ
    0
    У многих еще нет семьи, разумно невысокие требования к деньгам, но, при этом, масса амбиций и готовность вкалывать по 12 часов в день.…
    Важно. Я говорю об экспертах с опытом, скажем, 5 лет.

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

    Только значимость Картины Мира, как конкурентного преимущества, сильно переоценена. По факту, это помогает исключительно вам.


    Так конкурентное преимущество — это и есть то, что помогает лично вам.
    Если говорить про навыки, которые можно «продать» на собеседованиях — это совсем другая история. Ситуация с собеседованиями плохая, причем об этом говорят по разным странам. И она, наверное, будет становиться только хуже. С этим нужно просто смириться.

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

    Чем дальше тем больше будут различаться требования к работникам в разных компаниях. Где-то тебе поможет устроиться именно узкоспециализированная экспертиза, где-то кругозор. Но я согласен с Вашим советом. Нужно быть специалистом в одной-двух отдельных областях (инструментах), и в свободное время знакомиться с соседними областями «по верхам» чтобы понимать какие они бывают.
  • Методы расчета себестоимости
    0
    Это можно увидеть в SAP

    Это правда.
  • Методы расчета себестоимости
    0
    Согласен. Пока была задача просто составить структурированный справочник.

    Сделать гайд по выбору — отдельная задача, и она еще сложнее. Сделал бы следующей статьей, но уверен, что в ближайшее время не найду столько сил, времени и мотивации.
  • Perfomance-менеджмент через оценки — от идеи до бета тестирования
    +3
    Интересно почитать отзывы участников команды, насколько лучше стало работать после внедрения такой системы.

    Лично я помню, что встречал только одну максимально удобную модель работы — когда руководство не пытается помогать формальной оценкой или навязчивым контролем работникам (в любой форме: выставлением баллов, системой грейдов, выставлением взаимных комментариев, психологическими собраниями, ежедневными стендапами и пр. и пр.). Эту модель я помню практически во всех компаниях, в которых текучесть персонала была сведена к минимуму. Остальные системы по странному совпадению её увеличивают.
  • Логика ERP-системы реального времени: замещение планов фактами
    +1
    То есть сами данные о планах и фактах храним в ERP, а отчеты строим отдельно.

    Оперативный платежный календарь помните? Это и отчет, и основной инструмент управления платежами. Иногда даже вводить платежи прямо из него хочется
  • Интеграция в стиле BPM
    0
    Спасибо за пояснение!
  • К вопросу о запланированном устаревании
    0
    Простите, случайно минус нажал, исправить его похоже нельзя
  • Логика ERP-системы реального времени: замещение планов фактами
    0
    В консолидированной куб традиционно используется. В комментарии Глеба, я так понимаю, речь про куб в оперативном учете)
  • Логика ERP-системы реального времени: замещение планов фактами
    0
    Списание ДС — это и есть платежка, только там есть признак проведена она банком или нет.

    Точно, с 1С: Бухгалтерией перепутал.

    В некоторых организациях делали еще более глубоко. Бюжет -> Договор ->Заявка -> ПП.

    Так и надо. Но опять же, не типовом функционале

    2. Обычно такого не допускаем, т.к. бюджет верстается в разрезе ЦФО, и будет хрень

    Не понял, о чем вы, но это просто пример (который легко решается автозаполнением в платежке ЦФО равным значению из заявки — костыль, но все же), не суть принципиально

    В 1с есть регистры, которые сильно ускоряют такие вещи

    Я это только что написал:)
  • Логика ERP-системы реального времени: замещение планов фактами
    0
    Или про OLAP и CI был не стёб? Тогда второй абзац моего предыдущего комментария не читать:)
  • Логика ERP-системы реального времени: замещение планов фактами
    0
    Уже лучше. Даже поставил плюс.
    Но это именно частная реализация, а не решение в общем виде. До него еще много отрывов.

    1. Вы сами говорите, что в связке участвуют только Заявка на расходование и Списание. Как вы заметили, платежное поручение не учитывается (хотя я о нем писал, как и о «звонке из банка»).

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

    Это далеко от реалтаймовости. Если что, Таблица 1 в статье — не надуманная фантазия, она составлена на основе реальной практики.

    2. Условия по типу {Если в списании не указано подразделение — брать его из заявки} не прописаны. Данные берутся либо из заявки целиком, либо из списания целиком.

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

    Кстати, даже в разных продуктах 1С используются разные подходы. Например, еще одна реализация была, кажется, в УТ10, когда общий регистр представлял собой единый актуализированный срез по товарной операции, и разные документы в цепочке по очереди проводили в него данные. Причем когда свежий документ отменялся, в нее обратно подставлялись данные из предыдущего документа. Но у этого подхода другая обратная сторона — очень сложный код механизма проведения/отмены проведения, и при попытке его доработать (например добавить в цепочку еще один кастомный документ) разработчикам приходится очень непросто.

    Кстати, уже планировали с партнерами из сферы 1С сделать MVP на этой платформе для демонстрации решения в общем виде. Но пока это вопрос времени.
  • Логика ERP-системы реального времени: замещение планов фактами
    0
    Естественно. Я просто призываю это делать:)

    OLAP я упомянул на случай хайлоада, когда данных крайне много, а правила получения одного и того же расчетного показателя в разных отчетах различаются. С точки зрения логики это не имеет значения, это вопрос сугубо производительности.
  • Логика ERP-системы реального времени: замещение планов фактами
    0
    Рад бы предложить Вам на выбор один из двух вариантов:
    1. Вы выбираете любую конфигурацию 1С и находите несколько отличий от того, что написано в статье.
    2. Вы называете конкретную тиражируемую конфигурацию 1С и конкретный документ, где, как Вам кажется, эти проблемы решены. А я нахожу отличия и указываю Вам на них.

    Но пока что настоятельно предлагаю первый вариант.
  • Логика ERP-системы реального времени: замещение планов фактами
    +1
    Простите, но Вы либо не читали статью (внимательно), либо не работали с 1С (что вряд ли), либо мне остается только догадываться о причинах этого комментария.
  • Интеграция в стиле BPM
    0
    Хорошая, красиво оформленная статья.
    Но можно еще раз с точки зрения бизнеса перечислить конкретные задачи (проблемы) и привести примеры ситуаций, которые эти подходы решают?
  • Проблемы в собеседовании на позицию программиста
    +2
    А как мы дошли до того что умение ответить на вопрос «расскажите о себе» стало «умение в софт скиллы»?


    По сути, для технарей уровня программистов — уметь внятно отвечать на любые вопросы не о коде это именно софт скиллы. А тем более на такие абстрактные вопросы
  • Проблемы в собеседовании на позицию программиста
    +1
    Это понятно.
    Хороший технарь, умеющий в софт скиллы — это слишком фантастичная и дорогая вещь, чтобы ее ожидать в массовом применении.
  • Проблемы в собеседовании на позицию программиста
    +2
    Такие проблемные кандидаты с компостером в голове работодателю не нужны.


    Это только доказывает, что выросшие из разработчиков руководители, не умеющие в софт скиллы, могут быть еще хуже в управлении персоналом, чем HR-менеджеры.

    Извините за переход на личности, могу и ошибаться.
  • Проблемы в собеседовании на позицию программиста
    0
    Все верно, но до IT эта проблема только докатилась, в других сферах она была давно в таком же виде.
  • Коллеги, вы и меня огорчаете. Тоже
    +1
    Понятно, что есть массовый сегмент и есть профессиональный.
    Это как удивляться, что Гарри Поттера читают больше людей, чем учебник по архитектуре.

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

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

    5-10 плюсиков на узкоспециализированную статью — это емкость профессиональной аудитории на хабре. 3-4 тысячи просмотров. Проверено моей предыдущей и пока единственной статьей на этом аккаунте. Не так уж и мало.
  • Автоматизация бизнеса: начинаем разбираться
    –2
    Подробно не читал, пробежался по заголовкам, определениям и классификациям. Сложилось впечатление, что статья неплохая, но пришла к нам года из 2003.
  • Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (BI / ERP / EPM)
    0
    Если Вы настаиваете, убрал
  • Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (BI / ERP / EPM)
    0
    Откликнулся в ЛС.
    По итогу обсуждения можно будет дополнить статью.
  • Управление требованиями и сроками в методологии Oracle AIM BF
    0
    Как и в проекте, когда в начале проекта, заказчик не до конца понимая все последствия, подписывает документ с требованиями, налицо манипуляция со стороны подрядчика. Обратная ситуация столько же часто встречается, когда заказчик не раскрывает все сложности или детали в ТЗ, которые всплывают позже.

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

    Вопрос не в том, что нравится мне. Каждый метод хорош в своих условиях.

    Согласен.

    Спасибо.
  • Управление требованиями и сроками в методологии Oracle AIM BF
    0
    При «водопадном подходе» в начале проекта фиксируются требования, подписывается ТЗ, которое становится формальным основанием позже отказать в изменении требований или попросить за изменение дополнительные деньги. В итерационном подходе такая уловка не применима.


    Не понравилась одна эта фраза.
    Зачем называть «уловкой» подход, который честно используют в другой методологии.

    Если Вам нравится одна методология и не нравится другая — это Ваше дело. Вы можете использовать ее, описывать плюсы и минусы разных подходов, сравнивать их.

    Но в этой фразе, на мой взгляд, Вы допускаете манипуляцию.
  • Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (BI / ERP / EPM)
    0
    leossnet
    То есть следствием такой схемы расчета является гораздо более высокая сложность и ресурсоемкость плановых расчетов по сравнению с фактическими при агрегации даже обычных стоимостных показателей.


    Это все про расчеты «по кругу», мы про них уже поговорили.

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


    Если Вы считаете, что планирование «сверху вниз» не должно существовать — это отдельная тема для разговора.

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


    Если коротко и без максимализма: разобраться с методикой планирования немного сложнее, чем с учетом. Так?

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


    Да, но это все по сути про рекурсивность расчетов «снизу-вверх/сверху-вниз».
  • Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (BI / ERP / EPM)
    0
    leossnet

    1. Принципом отнесения данных к первичным (вводимым руками) или расчетным (вычисляемых компьютером). В учете первичными данными выступают преимущественно абсолютные значения показателей (количество потребляемых ресурсов, суммы продаж, суммы процентов по кредитам и т.п.), а в планировании — преимущественно относительные (нормы расхода потребляемых ресурсов, цены продаж, процентные ставки по кредитам т.п.).

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

    2. Учет всегда оперирует фактической информацией, которая является максимально полной и достоверной. При этом план всегда оперирует будущей информацией, которая по определению всегда недостоверна и фрагментарна.

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

    5. Учет представляет собой строго регламентированный процесс, регулируемый нормативными актами начиная с федеральных законов и заканчивая внутриведомственными инструкциями и стандартами. Для планирования отсутствует какая-либо регламентация со стороны государственных органов (за исключением государственных учреждений в рамках бюджетного процесса), в внутри организации процесс планирования в гораздо большей степени регулируется сложившимися практиками, чем внутренними нормативными актами.

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

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

    Тем не менее, планы могут ходить «по кругу» между отделами, и отделы могут корректировать только свою часть, не разбираясь в других разделах.
  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    0
    У РП в таком случае нет ни таких полномочий, ни таких функциональных знаний. Я думаю, что такие решения должны приниматься коллективно членами управляющего комитета.

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

    И что тогда моделировать? Оба варианта? А если расхождений сотни? Сколько версий процессов будет? Нет, фиксировать несоответствие и решать его надо сразу.

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

  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    0
    Кого Вы понимаете под руководителем проекта?

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

    Этот человек — не бизнес-аналитик (не тот, кто описывает эти процессы).
    Вопрос был скорее в том, как описывать тогда, когда все вольно или невольно врут.

    Как описывать — вопрос бизнес-аналитика.
    А что описывать — вопрос руководителя проекта.
    И ответ на него дается индивидуальный в каждой конкретной ситуации.

    Аналитику нужно
    1. Получить четкое задание на то, какие именно версии бизнес-процессов нужно смоделировать
    2. Допустим, РП ставит задачу выяснить реальные бизнес-процессы, при условии что пользователи их честно не расскажут
    3. Теперь аналитик в трудной ситуации, когда рассказы сотрудников заведомо ложные, и им нельзя верить. Что можно сделать:

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

    то просто выносить все найденные несоответствия на руководителя функционального блока и коллективно обсуждать их.

    Вынести можно то, что уже смоделировано!
    Если у нас есть модели всех процессов (и реальных, и целевых, и т.д.) — задача по моделированию решена. Дальше начинается совсем другая сфера функций.
  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    +1
    Идти к руководителю проекта с изложением ситуации и ждать, пока он разберется.

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

    Только зачем это?
    В теории сначала моделируется «как есть», потом проектируется «как должно быть», и после этого под «должно» пишется регламент.
  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    0
    Приходит специально обученный человек, называется «бизнес-аналитик», в отдел, и говорит: расскажите, как вы работаете. Сотрудники рассказывают ему про какой-нибудь свой бизнес-процесс, иногда показывают, аналитик задает уточняющиеся вопросы до тех пор, пока ему не становится понятно. Когда становится понятно, рисует модель бизнес-процесса (например, модель по BPMN).
    Так в каждом отделе предприятия, пока все нужные бизнес-процессы не будут описаны в моделях.

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

    Исключения — неожиданные косяки со стороны вендора (если внедряется новый функционал, который раньше не реверсился участниками проекта, или при обновлениях).
  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    +1
    Как это IT-система может «непрогнозируемо» подвести?
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    0
    Ну кнопку Run, конечно, они жмут после программирования)
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    0
    Согласен.

    Вот я не понимаю, зачем мне «грузить» разработчика необходимостью писать внутренние (не приемочные) тесты. И разработчики не понимают.

    Аргументация «ну попробуй, а если не понравится — попробуй еще много раз до тех пор, пока не понравится» (которая приводится в статье) мне не подходит, поскольку я и так добиваюсь достаточного понимания разработчиками задачи за счет своей постановки и/или, в крайнем случае, написания для них таких тестов самостоятельно. Поэтому хотелось бы, например, увидеть описание сфер, в которых такой подход необходим.
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    0
    У меня противоположное мнение: разработка на основе тестов может быть способом максимального разделения труда между постановщиком задачи и конечным разработчиком.

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

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

    Может быть, конечно, я говорю это из-за того, что я не видел TDD во всей красоте и могуществе.
  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    0
    Я не говорил, что их не нужно описывать. Просто так происходит.

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

    Конечно. Только при модели «Как надо» это нельзя выяснить. Это можно понять, когда понятная разница между тем, как надо, и как есть (другой вопрос, нужно ли и то, и то формально моделировать в нотациях или это можно понять из устных обсуждений — но это понимание обязательно должно быть).
  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    +1
    Ну на практике в большинстве случаев компании никакого описания ни реальных, ни целевых процессов не пишут.

    Вариант 2 — полностью согласен.
    Вариант 1 — теоретически я не против, просто моделирование желаемых процессов в таких случаях постоянно упирается в невозможность их реализовать (оказывается, что часть нужных данных некому вести, их нет или работники не готовы заполнять их на своем этапе, многие действия заранее не смогли предусмотреть или вспомнить при моделировании и т.д.). То есть, такая модель очень сильно отличается от того, что получится в результате. Но, опять же, это может быть специфика тех проектов, с которыми я работал.
  • Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы
    +1
    Трудно представить себе, чтобы кто-то из владельцев или топ-менеджеров крупного промышленного предприятия приобретал ERP-систему ради моды.

    Какая наивная фраза:)

    По поводу самого моделирования — мне кажется, нужно моделировать и как есть, и как должно быть, чтобы системному аналитику/консультанту было проще понять гэпы в бизнес-логике.

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