346

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 04 Июня 2010, 18:56:49 »

опять извиняюсь за задержку с ответом - не было возможности ответить раньше

Одна центральная база и зеркала это однако немножко не то (ИМХО), так как при таком варианте данные меняются в центре, а участки выступают получателями, но ничего не передают центру. Такая схема может быть реализована в том же Microsoft SQLServer'е. В моём же случае требуется двусторонний обмен, да ещё и желательно с офф-лайн репликацией, чтобы можно было файл выгрузки на дискете привезти или по электронной почте отправить.
Насколько я поняла, тот же MS SQLServer такого уже не поддерживает. Офф-лайн репликацию поддерживает, например, Sybase ASA и какой-то из очень дорогих вариантов Oracle. В моём дипломе предлагается бюджетный вариант реализации ИС на базе СУБД Firebird + IBReplicator от IBPhoenix. Хотя, честно говоря, сейчас сразу смотрела бы в сторону Sybase ASA.
В пользу зеркальных баз вижу следующие доводы:
- Справочники для выписки документов нужны все. В задаче ставится, чтобы водитель мог получить историю своего подотчета по ГСМ у диспетчера на любом участке. Поэтому документы тоже нужны практически все. Да в общем-то их не так уж и много, у меня в логической модели данных около 30 сущностей получается, штук 10 справочников, и 4-5 видов документов.
- Кроме того, на мой взгляд, репликацию зеркальных баз проще настраивать, да и в случае обвала какой-то из баз большая часть информации останется.
Довод в пользу не зеркальных  баз – уменьшение трафика. Но Интернет там не то чтобы дохлый, скорее возможны перебои. Т.е. когда интернет есть, то скорость обычно нормальная.

Вот и сделайте в своей пояснительной записке сравнение этих вариантов архитектур. Основы ведь Вы, в принципе, понимаете. А конкретика - почему такое-то решение в данном случае будет предпочтительнее? - это Ваше решение.

Кстати, поправка: с точки зрения использования нескольких реплицируемых баз, когда базы реплицируются один к одному, то каждая их них в момент работы с нею является "как бы" единственной и полной (как будто других нет). Поэтому использование репликации для пользователя прозрачно - ее вроде бы и не видно, да и выполняется она в нерабочее время. Останется вопрос в увеличивающемся объеме базы, но IMHO это не Ваш случай. Думаю, что основная проблема скорее в том, что у Вас МНОГО точек, где должна быть копия базы. Но сама система централизованная. Если Вы нарисуете архитектурную схему системы, показав на ней пользовательские модули и сами базы, которые соединены стрелочками репликации, а потом обведете все базы рамочкой, то Вам это должно броситься в глаза.

Другое дело, что из 1С справочники можно выгружать не полностью. Например, справочник «Номенклатура», где нужны-то только разные бензин и дизтопливо. Здесь да, надо предусмотреть какую-то форму выгрузки, чтобы бухгалтер ставил галочки и выгружал выбранные элементы или группу, а не все 150 видов гвоздей и бруса, только потому, что у них поменялась одна буква в наименовании или их перенесли в другую группу.
Ой, только сейчас поняла, что мне придётся ещё и в 1С как-то отслеживать изменение справочников с последней выгрузки. Ужас-то какой  .
В общем-то получается, что проблемы основные не столько с основной функциональностью системы, сколько с необходимостью взаимодействия с 1С и распределенностью.

Поправка формулировки: помимо проблем с функциональностью системы, существуют проблемы  с построением архитектуры системы, в частности при взаимодействии с 1С.
Но это нестрашно, Вы ведь для того и работаете/учитесь, чтобы [научиться] решать такого рода проблемы.

И потом у Вас по определению две базы: 1С и системы учета. "Тупо" выгружайте из 1С то, что поменялось, разделив предварительно на области видимости (ГСМ - не ГСМ), и не думайте выгружалось оно раньше или нет, нужно только чтобы оно легло на то же место с тем же кодом (чтобы дублей не было) - и всё!

О дублировании информации и сверке.
Допустим, наша организация решила закупить ГСМ и оплатила счет компании-поставщика.
Поставщик отгружает ГСМ, но не нам, а организации, с которой у нас заключен договор ответственного хранения (на каждом участке разные организации).
Затем с участка на склад организации хранящей ГСМ едет водитель бензовоза с доверенностью на получение ГСМ, где и заливает Дизтопливо в бензовоз. Там он получает расходную накладную, выписанную организацией-посредником, на основании которой в диспетчерской системе приходуется топливо (там указано только количество). Таких расходных накладных несколько на один оплаченный счет.
Поступление ГСМ по бухгалтерии оформляется в 1С документом «Поступление материалов» на основании счета-фактуры и расходной накладной выписанных организацией-поставщиком (там указаны и количество и сумма). Такие счет-фактура и расходная накладная по одному на один оплаченный счет.
Таким образом, пока у меня получается, что одно и то же поступление ГСМ учитывается 2 раза – в диспетчерской системе и в 1С. Причем количество поступивших ГСМ в документах и количество самих документов не совпадают. Тут необходима сверка.

Уж не знаю почему возникла такая схема, но не избавившись от нее, будет трудно поставить реальный учет - много сил будет уходить именно на сверку. С точки зрения бизнеса это должно сильно мешать. Возможно она (такая схема) как раз возникла из-за того, что невовремя приходили ПЛ, а сроки оплаты по счетам истекали, или может кому-то было лень разбираться с путевками. Кто знает???
Зачем Вам нужен двойной учет? Заводите в систему факты хозяйственной деятельности и будет Вам счастье и не будет нужна никакая сверка, кроме сравнения физических объемов ГСМ в бензобаке и написанного на бумаге - даже в формуле 1 такое делают :о))
Вы же ставите задачей ускорить доставку информации, вот и решайте ее, а полученное решение позволит устранить "перегибы на местах" и уменьшить дополнительную работу.

Получится такая схема документооборота. Наверное, надо почитать про DFD, что-то мы их очень невнятно проходили…

Вся система реализует некую специализированную схему документооборота. Не грузитесь пока синтаксисом DFD (тем более Вы ведь на UML вроде собирались моделировать, зачем Вам смешанное моделирование из разных методологий?), нарисуйте в понятных картинках. А когда разберетесь с суть задачи, найдете время нарисовать в виде семантически правильных моделей выбранной методологии.

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

Ну вот Вы уже пытаетесь ставить вопросы к своей системе - продолжайте в том же духе, только разделите их на бизнес-уровень (про документы и их заполнение/движение) и на уровень реализации (классы/объекты/данные/процедуры). Что будет, если произойдет то-то событие или какое-то другое - как это должно будет отразиться в системе (с помощью системы).

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

Ваша ответственность - Ваше и решение. Или наоборот :о)))

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

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

347

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 30 Мая 2010, 13:44:13 »

Прошу прощения за некоторую задержку с ответом - не было возможности и времени почитать форум

проще сделать централизованное решение

Распределенная система - требование к диплому, я его менять не могу. 

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

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

Ну вот, Вы же сами описываете свою систему как централизованную: единые справочники, движение информации в территориальном смысле, документы должны приходить в центральный офис и т.п.
Простейший способ - иметь одну центральную базу и ее образы (зеркала) на участках, такой механизм поддерживается основными производителями СУБД. Однако, у Вас одновременно и участков много (соответственно, их оснащение соответствующим оборудованием и ПО может представлять собой отдельную проблему), и интернет на них дохлый (что является уже другой проблемой). Разумным способом является регламентировать и сократить обмен информацией - слать только ту, что нужно. Например, обновление справочников слать ежемесячно или еженедельно, а данные о движении ГСМ - ежедневно.
Как вариант, подумайте над тем, чтобы не полностью зеркалить базы между участками, а только в той части, которая нужна для выполнения отдельных операций, например, первичная выписка документов.

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

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

Предполагалось, что в таблице «ГСМ в баках» хранится остаток ГСМ в баке транспортного средства на первое число месяца. Нужно к нему прибавить/отнять движение ГСМ по транспортному средству и получится количество на текущую дату.

Технически может быть проще несколько денормализовать данные об остатке ГСМ и сохранять не каждую операцию независимо друг от друга, а на каждую операцию хранить входящий остаток, изменение и исходящий остаток. Причем, т.к. операции могут быть приходные и расходные, то можно было бы хранить их в одной записи, но в разных колонках (пусть иногда и с нулевыми значениями). Я так однажды делал, это мне сильно упростило подготовку отчетов о движении объекта учета.

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

и да, и нет. Вы отталкиваетесь от того, что сначала описываете логику работы - логическую модель, а потом спускаетесь на уровень реализации. Но ведь и модель данных для СУБД, и диаграмму классов для приложения Вы все равно будете делать для разных компонентов приложения, и описывать все данные в Вашей системе они будут вместе, а не по отдельности. Поэтому при рассмотрении логического уровня Вы иногда должны учитывать особенности реализации, хотя лучше конечно идти последовательно.
Это же относится и к остальным (динамическим) диаграммам, которые взаимосвязаны.

348

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 24 Мая 2010, 00:45:28 »

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

Это понятно, но сформулируйте это проще, в терминах "снизить" или "повысить", "улучшить" и т.п.

Это я как проблему не выделяла, просто сообщила для сведения.

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

Я имела ввиду, что ежемесячно данные по движению ГСМ будут выгружаться в 1С.
Сами же данные в литрах (в диспетчерской базе) будут доступны в центральном офисе после каждой репликации с базами удаленных подразделений, которые должны происходить несколько раз в день.

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

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

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

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

когнитивный? :о)))
начните с главного. Что у Вас главное?

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

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

Хм, по модели вроде можно отследить где и сколько топливо находится, а модель всё равно какая-то корявая. Видимо, слишком много там от логической модели. Очень трудно от этого уйти.

Выделите места, где у Вас могут находиться ГСМ (нарисуйте их). Определить (выпишите) действия, которые могут происходить с ГСМ (это будут  Ваши стрелочки перемещений). Зафиксируйте состояния, в которых могут находиться ГСМ, и какие документы каждому переходу или состоянию соответствуют.
Проиграйте ситуацию от "на склад поступила тонна горючего", до "все горючее израсходовано и списано". Нарисуйте это на схеме пусть даже без моделирования (на UML).
Потом задайте вопрос: какие данные нужны на каждом этапе? Нарисуйте сущности (справочники пока можно не рисовать, только отмечайте? что нужно будет поместить в справочники) и опираясь на движение ГСМ (в соответствии со схемой) сопоставьте сущности с ним (когда и какие данные будут куда попадать)
Если сделаете последовательно и аккуратно, то найдете большинство ответов на безответные вопросы. А потом возьметесь за справочники.

За это отвечает сущность "ГСМ в баках", там должен быть ещё реквизит "Дата".

Ну и дальше как Вы ответите на этот вопрос (сколько осталось)?

А сущность "ГСМ на сотруднике" должна отслеживать на каком сотруднике в каком подразделении каких ГСМ сколько содержится. (У нас учет подотчета по сотрудникам идёт в разрезе подразделений)

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

349

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 23 Мая 2010, 17:34:18 »

1. Переформулировать проблему.

why not? как я понимаю, вас никто не сдерживает в этом вопросе

- необходимо иметь оперативные данные о движении и остатках ГСМ на участках

неплохо для начала.

- необходимости унификации процессов учета ГСМ на производственных участках

для чего процессы-то унифицировать? снижение накладных расходов? что-то еще?

Кстати, диспетчеры как главную проблему обозначили "Нет ГСМ", типа денег не хватает. 

нечеткая формулировка. ведь ее можно решить, например, с помощью получения кредита... в общем, подумайте еще о проблеме

2. Сделать в системе только количественный учет в литрах, суммовой не делать.

как первый шаг вполне себе ничего...

Дизтопливо в организацию поступает:
- от поставщика.
- по картам безналичной оплаты;
- за наличный расчет; (скорее всего этот вариант в системе рассматривать не будет)
- по талонам;

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

Сумма ГСМ, поступающих по картам безналичной оплаты, известна только в конце месяца, т.к. организация-поставщик даёт скидки, зависящие от общего объёма заправок за месяц. Литры при этом известны.

В конце месяца итоги по движению ГСМ, выгружаются в 1С. В 1С будет создаваться документы "Списание материалов" и "Перемещение материалов". Из системы выгружаются литры, в 1C рассчитываются по средней рубли.

а "ежемесячно" - это достаточно "оперативные данные о движении и остатках ГСМ"?

3. Попытаться сделать партионный учет. Хотя бы в проекте системы.
Ещё надо добавить в заправочной ведомости ссылку на документ, которым оформляется поступление ГСМ. Типа связь поступление - перемещение, в добавок к партионному учету.

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

Пыталась сделать диаграмму классов.

будьте проще. Помните в повести Носова "Витя Малеев в школе и дома", он решал задачу про орехи - изобразите свою схему подобным образом (для начала без какого бы то ни было моделирования): нарисуйте каналы поступления ГСМ;"бочку", куда это сливается; ТС/бензобак, которые заправляются; маршрут, на котором расходуется топливо; остаток топлива в бензобаке и т.п. - это будут состояния, для каждого изменения которых нужно иметь документ (впрочем они у вас в том или ином виде есть), нужно обеспечить прослеживание (чтобы в любой момент времени было ясно сколько всего топлива находится в системе и где именно - то ли на складе, то ли в бензобаке...), т.е. запасы ГСМ пополняются при закупке/поступлении топлива, а "исчезают" в процессе работы водителя/ТС - если работа не выполняется, то ГСМ никуда не исчезает.

У Вас по схеме нельзя, например, ответить на вопрос сколько топлива осталось в бензобаке?
А "поступление" и "заправка" - это что за сущности? "Поступило на склад" и "заправлено в бензобак ТС"?

350

Резюме / Re: Графическое резюме

« : 17 Мая 2010, 10:59:25 »

это надо в юмор перекинуть :о))

351

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 17 Мая 2010, 10:42:25 »

... это существенное усложнение алгоритма, и, возможно, неудобства для пользователя...

Задача-то в чем? "Неудобство пользователя" ... хм... так пользователю удобнее всего вообще не работать.
IMHO правильно поставленная цель должна достигаться правильным использованием правильного инструментария. Как глупо организовывать полный (в т.ч. партионный) учет для ввода какой-нибудь путевки, так же глупо путем регистрации только расходных накладных решать задачу избежаний потерь (краж)

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

У Вас разве стоимость топлива всегда постоянная? И что Вы делаете, чтобы рассчитать себестоимость?

Если смотреть шире, то для того, чтобы была "сквозная" связь всех документов, поступление ГСМ должно быть как-то обосновано.

Производственными планами, например. И нормами расхода.

Кроме того, наверное должна быть связь с платежными поручениями, договорами... Т.е. получается уже выход за границы простой учетной системы.

Вообще-то границы системы определяете Вы, как я это понимаю. Только IMHO они должны определяться с учетом подлежащих решению проблем.

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

Преподавателям часто приходится самим изучать совершенно новую дисциплину в течение семестра, у них элементарно нет возможности досконально вникать с предмет

А кому сейчас легко? Мне тоже часто приходится изучать совершенно новую (для меня) предметную область :о))) Про возможность досконально вникнуть в предмет скромно умолчу :о)))

352

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 14 Мая 2010, 10:33:40 »

Связи вроде нету.

Неправда - есть связь. Ищите!

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

Может уже настало время не только начать делать, но и сделать. Вопрос-то резонный.
То, что Вы пишете, о передаче материальной ответственности с одного лица на другое, безусловно, важно, но IMHO стоит вернуться (или начать) к простым вопросам, на которые должна давать ответ система, типа: сколько предприятие получило ГСМ всего, где оно, куда и сколько было использовано, почему именно столько и т.д. и т.п.
Тогда, глядишь, постепенно и ответите на вопрос главбуха.

353

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 13 Мая 2010, 20:25:54 »

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

354

Работа / Re: Какие существуют показатели работы аналитика

« : 12 Мая 2010, 17:23:23 »

для PM:
абсол. - бюджет проектов, выполненных без задержек по срокам и с необходимым качеством
относит. - соотношение бюджетов проектов, выполненных с опозданием, с неадекватным качеством, по отношению к бюджету качественных проектов без опозданий

355

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 12 Мая 2010, 17:13:00 »

Вот так значит. А сейчас задача у меня в основном умозрительная - написать диплом.   Т.е. построить модели, сочинить ТЗ и сделать работающее приложение.

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

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

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

356

Работа / Re: Какие существуют показатели работы аналитика

« : 12 Мая 2010, 14:34:57 »

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

т.е. получается тестировщикам будет выгодно, чтобы в системе было больше ненайденных багов до передачи ее в эксплуатацию.
Должно быть наоборот: тестировщикам должно быть выгодно, чтобы в переданной пользователям системе было МЕНЬШЕ багов. Поэтому их акцент должен быть направлен на усиленное тестирование системы ДО передачи ее в эксплуатацию.

Почитайте про "черную команду" у ДеМарко и Листера.

357

Задачи студентов / Re: ИС Учета ГСМ. Use case и другие

« : 12 Мая 2010, 13:53:34 »

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

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

Итак, Главная Проблема – хищение ГСМ, т.е. водители сливают дизтопливо и продают.

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

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

Эту проблему с помощью системы решить будет можно, но... для этого нужно будет нехило вложиться (инвестировать) в систему.

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

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

Четвертая проблема – организация выросла, стало много техники, сотрудников, и, соответственно, путевых листов. Бухгалтер не успевает их обрабатывать.

мало одного бухгалтера - берите еще. в нашей стране нет ничего дешевле человеческого труда :о(((

Пятая проблема – расчет нормативного и фактического расхода топлива по путевым листам проводится в Экселе, а итоги забиваются в 1С. Это не очень удобно и приводит возникновению ошибок.

Используемое средство - не проблема. IMHO подгонка нормативов и расхода в ущерб правильному учету - вот проблема!

Все эти проблемы появляются на последнем этапе движения ГСМ, когда дизтопливо было выдано водителям и должно быть списано путевыми листами. Ну или на этапе документального оформления списания ГСМ.

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

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

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

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

Разрабатываемая ИС как раз и должна автоматизировать работу диспетчерской службы.

это понятно.

К сожалению, навскидку конкретики по решению дать не могу...

358

Другие Методологии / Re: Методология описания банковских бизнес-процессов

« : 11 Мая 2010, 17:27:15 »

Ваш энтузиазм похвален, но все-таки как Вы будете это делать?
тем более если Вы этого никогда не делали и не работали исполнителем в этих бизнес-процессах.

359

Другие Методологии / Re: Методология описания банковских бизнес-процессов

« : 11 Мая 2010, 16:18:15 »

Ок. А если возьмем одну группу основных бизнес-процессов, например "Обслуживание юридических лиц", этого будет достаточно чтобы говорить о преимуществах моделирования? Как вы думаете для этого достаточно одного аналитика?

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

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

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

360

Другие Методологии / Re: Методология описания банковских бизнес-процессов

« : 11 Мая 2010, 13:49:19 »

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

P.S. типовые модели. а) у технологов :о)) б) недавно обсуждали - например sap.com