Прохожий2 ASU Поэтому наше программное обеспечение включает в себя модель предприятия и модель управления и... ничего более... Вы сможете реализовать JIT (канбан в том числе) в нашей системе, не прибегая к услугам программистов
to ASU. Хочется просто понять, как это все выглядит с технической точки зрения - есть набор базовых модулей, есть некий макроязык, с помощью которых возможно производить настройки под конкретное предприятие или вы сами дописываете нужную функциональность ? Я думаю непонимание в топике идет где-то на этом уровне, поясните, please. Хотя бы на самом простом уровне - что и КАК настраивается при внедрении - дописываются процедуры, какие-то настройки в базе делаются ?Я согласен с Вами в том, что недопонимание происходит на этом уровне. Но поймите правильно, корни этого недопонимания находятся значительно глубже. И если я буду сейчас рассказывать о частностях, то это не только не добавит понимания, а, наоборот, только усугубит ситуацию. В этом нет чьей-то вины или злого умысла... Строители Вавилонской Башни, наверное, были замечательными архитекторами, каменщиками и плотниками, но...
Да, есть набор подсистем, и в систему можно включить произвольное количество подсистем каждого класса и увязать их в единую систему. Это делается администратором системы. Система является распределенной со слабыми (настраиваемыми) связями. Это "конструктор", который включает в себя все необходимые подсистемы, для того чтобы создать любое предприятие. Аналогично мы можем "спуститься" в любую подсистему и выделить в ней те элементы, комбинируя которые, можно решить любую задачу в этой частной предметной области. Ранее я уже рассказывал о производственной подсистеме. Нет в системе никакого макроязыка. Прохожий2Какой-нибудь элементарный примерчик, что и как можно сконструировать в вашей системе (буквально - для того, чтобы ... пользователь должен поставить такие-то галочки, добавить по шаблону несколько записей и получить,что и требовалось )Посмотрите на описание того, как технолог создает тех.процесс: он описывает тех. операции и связывает их между собой, получая направленный граф (в простом случае, просто цепочку из ТО). По описанию ТП, полученному от технолога, администрация строит график работ по выпуску продукции. И т.д. Аналогичные сценарии существуют и для работы других подсистем. Такой пример устроит? (подозреваю, что нет...) Прохожий2Пользователь, настраивая систему какими понятиями/терминами оперирует (что есть в его распоряжении для манипуляций)Пользователь оперирует понятиями своей предметной области.

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

To all:
Сожалею, но завтра у меня очень напряженный день и я вряд ли смогу ответить на вопросы.
Если есть желание, то я могу попробовать сделать проекцию модели предприятия на ООП, о котором здесь шла речь. Безусловно, это не даст ответов на вопросы, скорее, наоборот, породит новые вопросы, но может быть такой пример позволит слегка изменить направление поисков ответов...

GaryaТолько один вопрос вдогонку. Ответьте честно.
Внедрение только Ваших программных средств ВМЕСТО всех остальных - без CAD, CAM, ERP, SCADA, CRM, SCM и т.д. и т.п. приносит эффект предприятию? Честно!Вы считаете данные, которые я представлял выше, - выдумкой, обманом? Я дал Вам повод усомниться в моей порядочности?
Мы не внедряем систему управления вместо перечисленных Вами систем. Данная система управления вполне удовлетворяет всем требованиям MRP-II системы (+производство, +кадры, +расширенная функциональность финансовой подсистемы и др.). Но при этом, предлагаемая нами система управления по своей структуре, организационным принципам и пр. существенно отличается от известных мне ERP (MRP-II) систем. GaryaИтак, ответьте честно.
1. Вы полагаете, что при устранении всего "несущественного для целей управления" это управление будет более эффективным? ERP-системы, в частности?Если Вы внимательно прочитаете то, что написали, то... сами найдете ответ (добавление/удаление чего-то несущественного не меняет эффективности). Это честный ответ? Garya2. Вы полагаете, что клиент, который в течении суток не получил ответа на заданный вопрос будет ждать, пока Вы, "эффективно" управляя СУЩЕСТВЕННЫМИ для управления средствами, сможете наконец на него ответить?Чтобы дать честный ответ на этот вопрос необходимо сделать массу уточнений (что за клиент? какой вопрос он задал? каковы критерии “эффективности”? и т.д., и т.п.). Возможно, подразумевается то, что критична скорость реакции на вопрос клиента. Да, так бывает. И использование автоматизированных систем позволяет повысить реактивность системы управления (снизить время отклика системы). Но для клиента, как правило, не менее важно и качество информации. Если мы быстро даем неправильный ответ, то... сами понимаете. В свою очередь, качество информации зависит от того, насколько адекватно модель, положенная в основу системы, отражает предметную область.
Это честный ответ? Garya3. Вы полагаете, что продукция, которая успевает устареть к тому моменту, пока будет закончен цикл подготовки производства, будет успешно продаваться?Нет, я так не считаю. Это честный ответ? Garya4. Если нет автоматизированного контроля за техпроцессом, значит нет необходимого времени реакции на отклонения в нем. Нет существенной части информации, с помощью которой можно контролировать производственный процесс. Для Вас вообще не важно, в какие сроки, в каком объеме, от каких источнико и с какой трудоемкостью поступает в систему информация?Простите, но мне непонятно, исходя из каких моих слов, Вы делаете подобное заключение? Во-первых, автоматизированный контроль (видимо речь идет о SCADA-системах), имеет свою цену. А значит надо считать эффективность использования данных систем. Это первое. Второе. Не всякий технологический процесс нуждается в постоянном контроле. Третье. Я никогда не отрицал полезности CAD, CAM, ERP, SCADA систем, но мне неизвестны случаи поставок всех этих систем в рамках единой системы. Это честный ответ? GaryaОбъясните тогда, я не понимаю. За счет каких именно факторов внедрение именно Вашего ПО (исключая все остальное, которое несущественно, потому что, как я понял, для эффективного управления существенно только Ваше) предприятие улучшает свое финансовое положение? Итак, честный ответ из расчета "меняем все несущественное на существенное" Ранее уже говорилось о том, что, прежде, чем браться за разработку и внедрение систем, мы потратили довольно много времени на разработку моделей предприятия и управления. И в рамках этих моделей мы можем обсуждать с руководством предприятия оптимальность существующей структуры предприятия и управления в конкретных условиях; методы изменения структуры предприятия и управлении при внешних и внутренних изменениях; критерии эффективности работы предприятия/управления в тех или иных условиях и пр.
Другими словами, мы говорим об эффективности (производства, логистики, управления и пр.) только после того, как согласовали с заказчиком наши модели, нашли общее видение, как предприятия, так и управления предприятием. Критерии эффективности – это расчетные показатели, а для того, чтобы посчитать надо иметь исходную информацию. И то, какая информация необходима в данных конкретных условиях, и то, как должна обсчитываться эта информация, и то, для чего производится обсчет, – все это берется из моделей. Помните, в одном из обсуждений я привел простую формулу расчета эффективности от внедрения комплексной системы управления (P = SUM [Vi * (Ci – Si)])? Данная формула – только частное следствие использования моделей, и ее саму можно раскрыть на моделях очень легко (показать, какие данные должны войти в эту формулу, периодичность проведения расчетов и пр.). А между тем, на многих форумах, в ответ на вопрос о том, как считать эффективность можно услышать множество противоречивых рассуждений от людей, которые занимаются внедрением систем.
Мы с Вами обсуждаем вопросы связанные с (автоматизированными) системами управления предприятиями, но сам феномен управления, по всей видимости, понимаем различно. Вы почему-то решили, что управление будет более эффективным, если мы облегчим условия труда рядовым сотрудникам, если дадим рядовым сотрудникам современные средства труда и т.п. Но при всей важности вопроса улучшения условий труда, снижения трудоемкости и пр., к эффективности управления он имеет опосредованное отношение. Можно с помощью самых современных CAD-систем разрабатывать морально устаревшую продукцию, а с помощью самых современных SCADA-систем контролировать устаревшие технологические процессы.
Я постарался честно ответить на Ваши вопросы, но считаю, что наш разговор может быть более конструктивным, если Вы скажите, что Вы понимаете под терминами “предприятие” и “управление”.

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

Объектно-ориентированный подход к построению моделей предприятий

Предварительное замечание
ООП базируется на трех ключевых концепциях:
- полиморфизм;
- инкапсуляция;
- наследование.
К сожалению, адепты ООП трактуют и применяют все три концепции различно. Можно взять известную работу Г. Буча “Объектно-ориентированный анализ и проектирование с примерами приложений на C++” и посмотреть, как он раскрывает эти идеи (для большей точности надо заметить, что Г. Буч определяет несколько иной состав “главных” элементов объектной модели: абстрагирование, инкапсуляция, модульность, иерархия; а так же три дополнительных элемента: типизация, параллелизм, сохраняемость. Однако, он все же рассматривает три перечисленные ранее концепции). Нельзя не заметить, того, что полиморфизм понимается весьма однобоко, только в рамках наследования: полиморфными могут быть свойства классов находящихся в связях наследования. В реальной жизни такое допущение ничем не оправдано. Инкапсуляция, как правило, признается весьма полезной, но... только частичная инкапсуляция (класс делится на защищенные и открытые части). И тот факт, что если один объект в программе “жестко привязан” к открытой части другого объекта (например, обращением к public method), не мы не имеем возможности изменить класс этого другого объекта без изменения и перекомпиляции программы, этот факт обходят стороной. Еще больше проблем всплывает при рассмотрении концепции наследования. Может ли быть наследование множественным или оно должно быть одиночным? В этом смысле интересен перл Г. Буча: “Часто агрегацию путают с множественным наследованием. Действительно, в С++ скрытое (защищенное или закрытое) наследование почти всегда можно заменить скрытой агрегацией экземпляра суперкласса. Решая, с чем вы имеете дело – с наследованием или агрегацией – будьте осторожны. Если вы не уверены, что налицо отношение общего и частного (is a), вместо наследования лучше применять агрегацию или что-нибудь еще.” Хороший совет :) особенно в свете того, что сам Г. Буч запросто путает понятия наследования и агрегации. Например, в начале книги он пишет, что “растение состоит из трех основных частей: корни, стебли и листья. А чуть позже при рассмотрении множественного наследования он наследует растение от плодов, цветов и пр. Но вопросы о том, почему если можно сказать, что растение состоит из листьев, то нельзя сказать, что растение состоит из цветов; почему, если растение – есть цветок, то растение – не есть лист, остаются без ответа.
Другим недостатком теории ООП является откровенная недооценка значимости агрегации. Дело в том, что любая система является агрегатом (по определению), но правила взаимодействия элементов системы, структурная организация и многие другие важные вопросы проработаны очень плохо... А без этого, крайне сложно объяснять вопросы построения систем с использованием ООП.
Зачем мне потребовалось такое вступление? Конечно, не для того, чтобы поругать Г. Буча и его сподвижников. Цель иная, показать, что в мире ООП даже основные концепции имеют разные толкования, что, безусловно, сказывается и на подходе к построению моделей предметных областей. На это накладывают свой отпечаток и не решенные вопросы гносеологии, теории систем, теории управления и пр. То есть, задача, которую нам предстоит решить довольно сложна, но мы все же сделаем попытку решить ее.

Объектно-ориентированный подход к построению моделей предприятий
(основная часть)

Построение классов предприятий
Адепты ООП уверяют, что начинать надо с исследования требований заказчика. Но нам будет трудно найти заказчика, которому бы нужна была... объектно-ориентированная классификация предприятий. Максимум, на что может ориентировать нас заказчик – это обследовать его предприятие. Но даже, если мы за свою трудовую жизнь обследуем большое количество предприятий, даже в этом случае вероятность получения хорошей классификации не очень велика.
С чего же следует начать? Очевидно, надо попробовать посмотреть на ту среду, в которой появляется и существует предприятие. Взаимодействие предприятия с внешней средой удобно описывать в терминах модели “требования-ограничения”. Внешняя среда, выдвигая требования к предприятию, должна учитывать, что каждому требование имеет свое ограничение, но и предприятие, выдвигая требования к внешней среде должно учитывать ее (среды) ограничения. Анализ модели “требований-ограничений” применительно к предприятию показывает неоднородность внешней среды. И мы можем разделить внешнюю среду на три группы, которые условно назовем): государство, рынок и собственники (в данном случае правильнее было бы говорить об инициаторах). Эти три группы, взаимодействуя между собой, создают предприятие с целью решения их собственных проблем . И создание предприятия нужно для того, чтобы удовлетворить требования этих трех групп. Можно и нужно структурировать требования, предъявляемые предприятию, каждой из групп, но я опущу эту часть, поскольку она слишком объемна и не так сложна (каждый при желании может выполнить эту работу сам). Для примера, собственники (инициаторы) могут иметь три мотива для создания предприятия: быть полезным обществу, самореализация и желание заработать. Часто исследователи видят только один (последний) мотив, а не их комбинацию, что приводит к ошибкам в результатах исследования. Исходя из мотивов, можно получить структуру требований, предъявляемых данной группой к предприятию.
Любое предприятие обязано отвечать на требования предъявляемые каждой группой. Предприятие прекратит свое существование (или его создание просто не состоится), если оно не будет удовлетворять требованиям хотя бы одной из групп. Государство закроет предприятие, если оно будет соответствовать требования закона о предприятии, экологическим или другим нормативам, КЗоТ и пр. Рынок отторгнет предприятие, выпускающее продукцию или оказывающее услуги, которые невос требованы , и такое предприятие разорится. Наконец, собственники закроют предприятие, если оно не удовлетворит их требования (возможно, закрытию будут предшествовать смены руководства предприятия).
И последнее замечание. В советские времена государство представало одно в трех лицах, тем не менее, все три группы явно присутствовали в аппарате государства: собственники – Госимущество; рынок – Госплан; государство – Минэкономразвития, Госстандарт, Минприроды и др. нормативно- контролирующие министерства и ведомства.

Итак, к настоящему моменту мы имеем структурированную совокупность требований, предъявляемых к любому предприятию. И, как сказано ранее, предприятие должно удовлетворять данной совокупности требований, а, значит, иметь в своем составе функционал реагирующий на требования внешней среды. Такой функционал, как правило, (частично) реализует бухгалтерия предприятия, которая предоставляет отчетность для государства и собственников предприятия. Частично, отчетные функции перед внешней средой выполняет отдел кадров предприятия (в области пенсионного обеспечения, соблюдения КЗоТ и т.п.).
Когда речь идет о любом предприятии, то это означает, что мы абстрагируемся от любых частностей конкретного предприятия, то есть, речь идет об абстрактном предприятии. Выразим эту мысль более четко: класс “Абстрактное Предприятие” (АП) содержит функционал, позволяющий взаимодействовать с внешней средой. Данный функционал удобно группировать по подсистемам, в частности, АП содержит в себе подсистему “Бухгалтерия” и может быть по необходимости дополнен другими подсистемами (отдел кадров, юридический отдел и пр.). Состав функционал АП определяется на основе анализа требований внешней среды к предприятиям.
На следующем шаге создадим новый класс предприятий, для этого к классу АП добавим финансовую подсистему. Или, говоря в терминах ООП, класс “Абстрактное Финансовое Предприятие” (АФП) наследуется от класса АП.
Далее создадим класс “Абстрактное Логистическое Предприятие” (АЛП), наследуясь от АФП, и добавив к наследнику логистические подсистемы (снабжение, склад, сбыт).
Наконец, создадим класс “Абстрактное Промышленное Предприятие” (АПП), как наследника от АЛП, имеющий производственную подсистему.
Полученная иерархия наследования содержит основные классы предприятий (можно показать, что эта иерархия полна, то есть, не существует предприятий других типов). Можно развивать базовую иерархию, например, можно на основе АФП создать “Абстрактный Банк” (АБ) и “Абстрактный Фонд” (АФ), и “Абстрактную Финансовую Компанию” (АФК). От АБ можно получить разные виды банков, от АФ различные финансовые фонды (инвестиционные, венчурные и пр). От АФК можно наследовать трастовые и страховые компании. Очевидно, что разница между этими предприятиями состоит в оказываемых услугах, но базовые принципы работы финансовой подсистемы будут одинаковы во всех перечисленных предприятиях.
Аналогично можно наследовать от АЛП абстрактные транспортные и торговые компании (АТК и АТорК). При создании АТК для нас совершенно неважно, какой транспорт (сухопутный: автомобильный или железнодорожный; воздушный, водный: морской или речной) используется. Общие принципы приема и передачи груза остаются одинаковыми, что значительно увеличивает объем повторно используемого “кода”. То же самое справедливо и для АТорК, базовые принципы торговли остаются неизменными независимо от профиля, ассортимента и объемов продаваемых товаров.
Наконец, наследуясь от АПП можно создать все классы промышленных предприятий от добывающих до утилизирующих отходы. Если существо производственной подсистемы в абстрактном классе (АПП) передано верно, то настройка на конкретную отрасль или конкретное предприятие не превышает нескольких процентов от общего объема кода.

Можно (нужно) верифицировать полученную нами базовую иерархию классов предприятий. Из уроков истории мы помним, что на заре цивилизации существовало натуральное хозяйство. Община (племя, род и пр.) производила продукцию для собственных нужд. С развитием средств труда стали образовываться излишки, которыми община обменивалась со своими соседями (это крайне примитивное изложение, но за неимением возможности сделать более подробное описание... воспользуемся этим, но оно имеет серьезные изъяны!). По мере дальнейшего развития средств труда и, следовательно, производительности, количество продукции возрастало, что положило начало рыночному обмену. Появилась экономическая абстракция первого рода – товар. Разнообразие товаров вызвало к жизни логистические (торгово-транспортные предприятия).
При дальнейшем развитии производительных сил произошло одновременное увеличение количества и ассортимента товара, а также выросло и количество рынков. Стало крайне сложно помнить “кросс-курсы” различных товаров друг к другу на различных рынках. Как следствие, сформировалась абстракция второго рода: деньги (“всеобщий эквивалент”). Появление денег повлекло за собой развитие денежных отношений и, далее, появление и развитие финансовых организаций.
Как видно из этого (вульгарного) пересказа, история развития экономических отношений подтверждает выстроенную ранее иерархию классов предприятий (только рассмотрена в обратном направлении).

Иерархия классов предприятий имеет в своей основе модель предприятия и является только частным случаем рассмотрения этой модели. Сама по себе модель гораздо богаче, рассматривая ее можно двигаться в двух направлениях: в сторону подсистем, рассмотрения их рои и структуры в рамках всего предприятия; но можно двигаться и в сторону макроэкономических моделей. Каждый путь по своему интересен. Интересно собирать различные предприятия, комбинируя подсистемы, меняя связи и пр. С другой стороны, интересно и образование холдингов и корпораций, и далее к построению экономических моделей территорий и стран. Но это очень большой объем материала.

Мы с Garya после обсуждения в ICQ пришли к взаимопониманию... полного непонимания друг друга :) И теперь у меня нет причин отвечать на его вопросы на форуме.

Прохожий2Было бы интересно, я думаю никто не будет против ?Вас устраивает описание объектной иерархии предприятий?

IT-христОфигеть можно от товарища ASU. Если он живет в нашей стране и понимает как реально делаются "серые" деньги, то автоматизировать ЭТО вообще невозможно - можно только имитировать автоматизацию. Этой имитацией или эмуляцией в основном многие и занимаются. И это всего лишь следствие нашей политической несвободы, которая отображается и на экономику. Лечить такие проблемы надо в другом месте. Например на забастовках и митингахАвтоматизировать можно "делание" любых денег: "белых", "серых" и "черных". А вот чего делать не надо, так это скатываться к попу-лиз-му... (IMHO, конечно). IT-христЕсли же экономика соответствует заявленной политике руководства страны, то большинство предприятий будут "просты" для автоматизации и без всяких завиральных идей о поиске смыслаУгу... Значит все дело в "барине" ("Вот приедет барин, барин нас рассудит")?.. То бишь, примут "правильное" решение президент и/или правительство, и все само собой автоматизируется... Только опыт развитых стран с "правильной" экономикой показывает весьма плачевные результаты (до 70% провалов). Может капиталистам всего мира выйти на забастовку, профинансировать строительство баррикад?.. :) Выбрать "правильных" президентов, назначить "правильные" правительства и не выбрасывать кровные миллионы на автоматизацию. Подумайте сами, сегодня бюджет крупной IT-корпорации больше, чем бюджеты многих стран. IT-христСмысл любого предприятия это получить прибыль и поделится с гос-вом в виде налоговНу, вот и "откровений" дождались... Все оказывается так "просто"! Смысл предприятия - прибыль, а смысл человека - жрать... IT-христА вот какими методами достигается прибыль, это уже не задача автоматизации, а задача налоговой полиции. Если методы легальны, то они вполне укладываются в канонические MRP и ERP и здесь не надо выдумки всякие строить(без комментариев)

Уважаемый, Garya, прежде, чем Вы "замолкните навечно", позвольте дать Вам один маленький совет: научитесь говорить от своего имени. То, что Вы домысливаете за меня, - это не мои мысли, а Ваши представления о моих мыслях. Вы публично пытаетесь выдать свои представления за мои мысли, это, как минимум, неэтично.

IT-христЕще раз повторю для ASU - вы не сможете автоматизировать серый и черный учет только потому, что вам про него не расскажут ни директор ни глав.бух. только потому, что они боятся. Соответственно, "смысл" этой "игры" вы будете выдумывать, а не знатьСпасибо, за повторение... Замечу только, что для автоматизации учета совсем не обязательно знать, какой учет будут вести пользователи. По всей видимости, для Вас количество "учетов" определяется произведением количества предприятий на "градации серости"... IT-христЯ всего лишь говорил о том, что "теневая" экономика в "теневой" политике работает непрозрачно. В "прозрачной" политике экономика тоже работает "прозрачно". Те, кто хотят играть не по правилам - те терпят провал в установке систем учета! в любой обстановкеПолучается, что 70% предприятий в мире играет не по правилам. Странная логика, однако...
IT-христДа, смысл предприятия - прибыль. А человека - жрать. Такова точка зрения систем управления ресурсами Это Ваша точка зрения на систему управления ресурсами.