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

Хо-хо, мой мозг испорчен 1С-ом.

Ну выложу ещё до кучи логическую модель.

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

Продолжение

Вернусь к одному из первоначальных вариантов.
Опять диаграмма Use Case.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

это понятно.

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

Водолей, я это все понимаю, и со всеми Вашими выводами, в основном, согласна.

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

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

Тогда набрали диспетчеров, посадили их за решение на базе Рарус:Автотранспорт + 1С:Бухгалтерия 7.0. Этот Рарус оказался каким-то "корявым", а конфигурация была с большими изменениями и старый релиз.
Внедрялось решение на 1С, так как на участках кроме диспетчера сидел ещё и бухгалтер, документы которого требовалось видеть максимально оперативно и в общей базе. Обмен данными шёл через УРИБ.

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

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

Кстати, бюджеты внедрялись, вроде составлялись, утверждались. Но тут проблема была ещё и в том, что средства трудно изыскать в рамках утвержденного бюджета (!). И это не только от неправильного планирования, но и от того, что заказчик не рассчитывался в сроки, установленные договором.

Да, все проблема в людях, даже скорее в отношении к ним, в отношении к подбору персонала.
На предприятии очень большая текучесть кадров - ВСЕХ - рабочих, диспетчеров, начальников отделов.


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

Варианты подобного развития событий имеются...

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

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

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

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

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

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

Хм... я вроде так и хотела делать.

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

Думаю, что стандартного "все делается вручную, медлено, неудобно и с ошибками" будет достаточно.

Типичное заблуждение имхо.

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

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

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

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

А я и не утверждала, что ВСЕГДА делает. Часто делает, часто - нет, а иногда новый способ производит революцию в области внедрения.

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

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

а какая-то связь между поступлением и заправкой есть?

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

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

Ох, действительно, имею трудности. Лучше и не скажешь. У меня всё скатывается к конкретике, к логической модели. Попробую продумать этот вопрос.

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

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

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

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

Почитала форум, почитала Коберна, переделала диаграмму ВИ, написала набросок сценариев.
Действительно, ДВИ - это Зло, больше думаешь не о самих вариантах, а о том, чтобы красивее их представить.

Покритикуйте, пожалуйста! 

Вариант использования "Войти в систему"

Код: [Выделить]

ВИ: Войти в систему
ID: 1
Краткое описанисе:
Вход в систему
Основное действующее лицо:
Диспетчер или Бухгалтер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Сотрудник запускает приложение.
2. Система показывает экран для входа.
3. Сотрудник вводит свои Логин и Пароль.
4. Система проверяет информацию.
5. Система устанавливает права доступа.
6. Система показывает основной экран.
Постусловия:
1. Пользователь успешно вошёл в систему
2. Пользователю установлен определенный набор прав.
Альтернативные потоки:
Нет.

Вариант использования "Оформить поступление ГСМ"

Код: [Выделить]

ВИ: Оформить поступление ГСМ
ID: 2
Краткое описание:
Регистрация поступления ГСМ от поставщика
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Поступление ГСМ»
2. Диспетчер выбирает вид поступления (за наличный расчет, по талонам, по картам безналичной оплаты, от поставщика).
3. Система запрашивает необходимые данные в соответствии с выбранным видом поступления.
4. Диспетчер вводит запрашиваемые данные.
5. Диспетчер подтверждает правильность заполнения документа.
6. Система запрашивает подтверждение проведения документа – оператор подтверждает.
7. Система сохраняет документ «Поступление ГСМ» в БД.
8. Система отражает в БД поступление ГСМ в подотчет выбранному МОЛ.
Постусловия:
1. В БД сохранен новый документ «Поступление ГСМ».
2. В БД отражено движение ГСМ.
Альтернативные потоки:
Нет.

Вариант использования   "Оформить перемещение ГСМ"

Код: [Выделить]

ВИ: Оформить перемещение ГСМ
ID: 3
Краткое описание:
Регистрация передачи ГСМ от одного МОЛ другому
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Перемещение ГСМ».
2. Система запрашивает реквизиты документа.
3. Диспетчер вводит запрашиваемые реквизиты.
4. Диспетчер подтверждает правильность заполнения документа.
5. Система запрашивает подтверждение проведения документа – оператор подтверждает.
6. Система сохраняет документ «Перемещение ГСМ» в БД.
7. Система проверяет корректность введенных данных и отражает в БД перемещение ГСМ с подотчета одного МОЛ в подотчет другого МОЛ.
Постусловия:
1. В БД сохранен новый документ «Перемещение ГСМ».
2. В БД отражено движение ГСМ.
Альтернативные потоки:
На подотчете МОЛ-источника не достаточно ГСМ для списания.

Вариант использования "Оформить перемещение ГСМ: На подотчете МОЛ-источника недостаточно ГСМ для списания"

Код: [Выделить]

ВИ: Оформить перемещение ГСМ
ID: 3.1
Краткое описание:
Система сообщает пользователю, что на подотчете МОЛ-источника не достаточно ГСМ для списания
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается с шага 7 основного потока
2. Система сообщает, что на подотчете у МОЛ-источника недостаточно ГСМ
Постусловия:
1. В БД не было отражено движение ГСМ
Альтернативные потоки:
Нет

Вариант использования "Оформить заправку транспортного средства"

Код: [Выделить]

ВИ: Оформить заправку транспортного средства
ID: 4
Краткое описание:
Регистрация заправки транспортных средств из бензовоза
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Заправочная ведомость».
2. Система запрашивает реквизиты документа.
3. Диспетчер вводит запрашиваемые данные.
4. Система рассчитывает общее количество и сумму ГСМ и производит проверку наличия на подотчете заправщика данных ГСМ.
5. Диспетчер подтверждает правильность введенных данных.
6. Система запрашивает подтверждение проведения документа – оператор подтверждает.
7. Система сохраняет документ «Заправочная ведомость» в БД.
8. Система проверяет корректность введенных данных и отражает в БД перемещение ГСМ с подотчета заправщика в подотчет Водителям.
Постусловия:
1. В БД сохранен документ «Заправочная ведомость».
2. В БД отражено движение ГСМ.
Альтернативные потоки:
На подотчете у заправщика недостаточно ГСМ

Вариант использования "Оформить заправку транспортного средства: На подотчете у заправщика недостаточно ГСМ"

Код: [Выделить]

ВИ: Оформить заправку транспортного средства
ID: 4.1
Краткое описание:
Система сообщает пользователю, что на подотчете МОЛ-источника не достаточно ГСМ для списания
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается с шага 8 основного потока.
2. Система сообщает, что на подотчете у заправщика недостаточно ГСМ.
Постусловия:
1. В БД не было отражено движение ГСМ.
Альтернативные потоки:
Нет

Вариант использования "Создать путевой лист"

Код: [Выделить]

ВИ: Оформить путевой лист
ID: 5
Краткое описание:
Создание нового документа «Путевой лист»
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Путевой лист».
2. Диспетчер выбирает вид путевого листа (легкового автомобиля, грузового автомобиля, тяжелой техники).
3. Система запрашивает данные в соответствии с выбранным видом путевого листа.
4. Диспетчер вводит запрашиваемые данные.
5. Диспетчер выбирает опцию печать документа «Путевой лист».
6. Диспетчер подтверждает правильность введенных данных.
7. Система запрашивает подтверждение проведения документа – оператор подтверждает.
8. Система сохраняет документ «Путевой лист» в БД.
9. Система распечатывает документ «Путевой лист».
Постусловия:
В БД сохранен новый документ «Путевой лист».
Альтернативные потоки:
Нет.

Вариант использования "Рассчитать путевой лист"

Код: [Выделить]

ВИ: Рассчитать путевой лист
ID: 6
Краткое описание:
Списание ГСМ с водителя путевым листом
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Водитель
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер открывает для редактирования сохраненный документ «Путевой лист».
2. Диспетчер заполняет незаполненные реквизиты Путевого листа.
3. Система рассчитывает расход топлива по нормам и по факту.
4. Диспетчер подтверждает правильность расчета.
5. Система запрашивает подтверждение проведения документа – оператор подтверждает.
6. Система сохраняет отредактированный Путевой лист в БД.
7. Система проверяет корректность введенных данных и отражает в БД списание ГСМ с подотчета водителя.
Постусловия:
1. В БД сохранен отредактированный документ «Путевой лист».
2. В БД отражено списание ГСМ с подотчета водителя.
Альтернативные потоки:
На подотчете водителя недостаточно ГСМ

Вариант использования "Рассчитать путевой лист: На подотчете водителя недостаточно ГСМ"

Код: [Выделить]

ВИ: Рассчитать путевой лист
ID: 6.1
Краткое описание:
Списание ГСМ с водителя путевым листом
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Водитель
Предусловия:
Нет
Основной поток:
1. ВИ начинается с шага 8 основного потока
2. Система сообщает Диспетчеру, что на подотчете водителя недостаточно ГСМ
Постусловия:
1. В БД не было отражено списание ГСМ с подотчета водителя
Альтернативные потоки:
Нет

Вариант использования "Формировать отчеты об остатках и движении ГСМ"

Код: [Выделить]

ВИ: Формировать отчеты об остатках и движении ГСМ
ID: 7
Краткое описание:
Формирование отчетов об остатках и движении ГСМ
Основное действующее лицо:
Диспетчер или бухгалтер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию «Сформировать отчет».
2. Диспетчер выбирает вид отчета.
3. Система запрашивает параметры формирования отчета (период, фильтр, группировку, итоги).
4. Диспетчер вводит параметры отчета.
5. Диспетчер подтверждает правильность введенных данных.
6. Система осуществляет отбор и обработку данных согласно заданным критериям.
7. Система выводит на экран форму отчета.
Постусловия:
Сотрудник получил отчет.
Альтернативные потоки:
Нет.

Вариант использования "Произвести выгрузку данных о движении ГСМ для системы 1С:Предприятие"

Код: [Выделить]

ВИ: Произвести выгрузку агрегированных данных о движении ГСМ для системы 1С:Предприятие
ID: 8
Краткое описание:
Произвести выгрузку агрегированных данных для системы 1С:Предприятие.
Основное действующее лицо:
Главный диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Наступил конец месяца
Основной поток:
1. ВИ начинается, когда Главный диспетчер выбирает опцию «Выгрузить итоги за месяц».
2. Система отбирает проведенные документы за месяц
3. Главный диспетчер подтверждает правильность отбора документов и выбирает опцию «Начать выгрузку».
4. Система выгружает итоги по документам.
5. Диспетчер подтверждает правильность выгрузки.
6. Система присваивает выгруженным документам статус «Выгружен».
Постусловия:
1. Создана выгрузка итогов за месяц для 1С.
2. Выгруженные документы помечены как «Выгруженные».
Альтернативные потоки:
Нет.