Точная терминология имеет значение для непустых споров:Цитата:
Сообщение от Финансовый профан
здесьЦитата:
Уважаемые сотрудники офисов, будьте точнее ...
С уважением, менеджер по экологии офисов, тётя Таня
Вид для печати
Точная терминология имеет значение для непустых споров:Цитата:
Сообщение от Финансовый профан
здесьЦитата:
Уважаемые сотрудники офисов, будьте точнее ...
С уважением, менеджер по экологии офисов, тётя Таня
Единственный правильный вариант это конечно ВТОРОЙ, когда информация вводится в местах возникновения - это прописная истина.
Хотя на практике в больших компаниях бывает более расширенный подвариант варианта 2:
- менеджеры по продажам вводят заявки клиентов
- множество заявок автоматически обрабатывается программой для выявления реализуемости и далее все уточненные заявки поступают на утверждение руководителю менеджеров. Неутвержденные позиции менеждерами могут быть перенесены в заявки следующих дней (а также служат для информирования клиентов о задержках в поставке товара и принимают с ними решение, что делать дальше)
- на базе утвержденных на складе производится резервирование товара, а затем физический отбор (упаковка возможно). и т.д.
Важен единсвенный ввод документа, отсутсвие его поторного ввода, корректировка только в виде появления нового, чтобы отследить как все двигалось и менялось.
Важным моментов является ведение самой номенклатуры товара. Это большая проблема на самом деле. Наименования поступающей продукции и ее коды могут отличаться от тех, что на предприятии. При поступлении новой продукции (сырья) важно не ввести повторно туже самую позицию. Если ввод осуществляется распрееленно, то тут еще все сложнее - обычно все равно в каком-то одном месте вводится номенклатура новая.
АСУ тут не при чем вообще.
Можно на программу возложить обязанности по контролю правильности, своевременности ввода информации в БД. Так мы делали, что программа автоматически в заданные дни делает сама отчеты о наружениях регламента ввода документов и рассылает из по интранету ответсвенным лицам. Если кто-то например, не имеет права отпускать товар какой-то или может отпускать его полько до 16 00, то программа ссобщает в последствиях о факте такоего отпуска отчетом руководству. Так можно бороться за корректность ввода данных.
ага, датчик, кассовый аппарат, весы и т.д. - не требуют поверки, ревизии?Цитата:
Сообщение от igor12345
а менеджеры ?
не упрощайте.
И это тоже к написаному мной ниже. Бухгалтеру невыгодно все проводить, а затем перепроводить,т.к. весь месяц все корректируется. И поэтому ему лучше все провести, когда все уляжется - меньше работы. Это конечно противоречит принципам бухучета о вводе документов, но совершенно не практично в российских условиях когда многое выполняется ЗАДНИМ числом.Цитата:
Сообщение от vss
С точки зрения управленческого учета, оперативного учета понятно, что документы должны вводиться в местах первичного получения, возникновения. Бухгалтера действительно работают только по документам, но кем они были пребразованы в электронный вид.
Почему надо вводить в местах возникновения? Нет многократной передачи информации, промежуточных сверток каких-то и т.д., т.е. тратиться намного меньше времени от момента возникновения, до момента когда она становится доступной всем сотрудникам компании ( в рамках прав достпупа конечно).
;) возникает у клиента - поставщика или потребителя, если уж быть последовательным в рассуждениях.Цитата:
Сообщение от igor12345
Извините, не понял фразы :) что возникает?Цитата:
Сообщение от Игорь Захарченко
это был тест пример обработки информации в месте возникновения - появились разночтения.так что в местах возникновения информации не достаточно лишь ее фиксирования)Цитата:
Сообщение от igor12345
во-во. как же реализовать алгоритм "переспрашивания"? в местах возникновения информации)
Цитата:
Сообщение от igor12345
Посему ввод информации стоит поручить сотрудникам грамотным, компетентным в ИТ, а также в той предметной области, из которой и "возникает" информация. Пусть это будут так называемые администраторы БД 1с.
Обычно принято называть администраторами баз тех, кто поддерживает БД. Т.е. обеспечивает ее востановление после сбоев, ведет архивы БД, поддерживают обмен и т.д. По поводу ввода обычно как-то не предусматриват.Цитата:
Сообщение от Игорь Захарченко
Если программа внедрялась профессионально , то у каждого оператора (т.е. сотрудника работающего с БД 1С через свой интерфейс) должна быть инструкция, по которой он вводит, корректирует информацию, получает отчеты. К тому же сам интерфейс часто не дает вводить некорректные документы. Поэтому особой компетенции по работе с программой в таком случае не нужно. Что и как воодить написано в инструкции пользователя.
ПОд информацией понимается не слова, а документ, предусмотренный документооборотом компании.Цитата:
Сообщение от Игорь Захарченко
;) а кто предусмотрел?Цитата:
Сообщение от igor12345
Автор топика, к сожалению, не сообщил нам о том, кто поддерживат СУБД Oracle у них на фирме, и насколько профессионально в его компании внедряется 1с, и какой там интерфейс, и написаны ли инструкции. Да и тот, кто внедрил у них на фирме документоооборот, возможно предвидел и внедрение 1с. Посему мы решили перестраховаться, и говорить об институте администраторов баз данных 1с ;) на всяк случАй. мало ли что)Цитата:
Сообщение от igor12345
подводных камней гораздо больше, уважаемый. А то что вы описали это даже не подводные камни, а так, легкая рябь. Решается простым регламентом с выделением классов-подклассов-подпод...номенклатуры. и назначением отдельного стаффа если документов, контрагентов, договоров, номенклатуры и т.п. многоЦитата:
Вопрос в том, какие подводные камни Вы видите при первом и втором подходе? Буду рад любой критике и совету
Елена Яковлева, не вводите людей в заблуждение! Админы БД занимаются обслуживанием БД
Перво-наперво надо для самих себя определить зачем эта самая УПП вам нужна. Если уж так ее хотите, то наверняка ждете от нее не просто бухгалтерии с налогами. На самом деле УПП довольно гибкая система, но как и все продукты 1С она похожа на конструктор лего с одним отличием - кубики придется выпиливать самим.
Как процесс внедрения кратко и сверху вижу я:
1. Определить пользователей данных системы;
2. Определить задействованные вшитые системы учета (РБУ, УУ, МСФО, Бюджетирование);
3. Определить какие данные будут нужны пользователям (хотя бы какие им требуются сейчас. Дальше аппетиты будут расти, а обслуживать их придется вашим IT-шникам);
4. Определить какие данные являются общими для нескольких систем учета;
5. Описать справочники (пока не лезть в систему!!! Сначала формализовать все на бумаге, иначе потом все переделывать и не дай Бог на уже функционирующей базе). Определить точно все ограничения при вводе элементов справочников (например для номенклатуры нужно во-первых прописать наиболее полно название материала с возможностью однозначной идентификации (особенно для основных средств), во вторых по названию кладовщик должен абсолютно точно сопоставить запись на мониторе с тем, что реально лежит у него на складе).
И только после этого уже заполнять справочники в системе.
Мой вам совет пригласить со стороны хорошего методолога + архитектора баз данных 1С с хорошим опытом внедрения. + можно программеров со стороны. Завязать их всех на тесное сотрудничество со своим отделом IT, чтобы они в процессе учились. После внедрения администрировать систему должен ваш отдел IT. Если понадобится поменять в нем несколько сотрудников, это надо сделать. Ничего страшного в этом нет. Меняются задачи - меняются компетенции - меняются люди.
Главное на протяжении всего процесса надо каждую секунду помнить, что систему вы внедряете для ее ПОЛЬЗОВАТЕЛЕЙ, а не чтобы была. Поэтому она должна максимально удовлетворять всем их потребностям, причем всех одновременно.
По поводу дальнейшего наполнения данных. Ввод 90% документов можно возложить не на работников бухгалтерии (и нужно). При этом проводить документы в управленческих системах учета. Это обеспечит оперативный контроль. В конце месяца с приходом документов бухи уже заведенные документы будут проводить (либо не проводить) в РБУ. Если что-то не проведут надо выяснить причины и разработать механизм контроля сходимости данных разных систем. В них вполне могут быть разные данные, но все разницы вы должны уметь объяснить, иначе будет система электронного хаоса. Таким образом ежедневно можно будет получать оперативные отчеты на основе данных УУ, а в конце месяца бухгалтера будут иметь данные для формирования отчетности в своей системе.
;)Цитата:
Сообщение от balabol
Классификация АБД
Существует несколько видов администраторов БД, а их обязанности вполне могут отличаться от компании к компании. Вот характеристики некоторых типов АБД и занимаемых ими положений:
- Оперативные (operational) АБД:
- манипулируют дисковым пространством
- наблюдают за текущей производительностью системы
- реагируют на возникающие неисправности БД
- обновляют системное ПО и ПО базы данных
- контролируют структурные изменения БД
- запускают процедуры резервного копирования данных
- выполняют восстановление данных
- создают и управляют тестовыми конфигурациями БД
- Тактические (tactical) АБД:
- реализуют схемы размещения информации
- утверждают процедуры резервного копирования и восстановления данных
- разрабатывают и внедряют структурные элементы БД: таблицы, столбцы, размеры объектов, индексацию и т.п.; сценарии(scripts) изменения схемы БД; конфигурационные параметры БД
- утверждают план действий в случае аварийной ситуации
- Стратегические (strategic) АБД:
- выбирают поставщика БД
- устанавливают корпоративные стандарты данных
- внедряют методы обмена данных в рамках предприятия
- определяют корпоративную стратегию резервирования и восстановления данных
- устанавливают корпоративный подход к ликвидации последствий аварии и обеспечению доступности данных
- Старшие (senior) АБД:
- досконально знают свой персонал
- пользуются высоким спросом
- могут написать скрипт, который освободит их из запертого сундука, брошенного в океан, и чрезвычайно гордятся своими произведениями
- тратят уйму времени на подготовку младших АБД
- очень ценятся руководством и получают бешеные деньги
- Младшие (junior) АБД:
- мечтают стать старшим АБД
- не слишком сильны в написании скриптов
- имеют большую склонность к использованию средств управления БД
- тоже неплохо получают
- Прикладные (application) АБД:
- в курсе информационных нужд компании
- помогают в разработке прикладных задач
- отвечают за разработку схемы и ее изменения
- вместе с системным АБД обеспечивают должный уровень резервирования/ восстановления данных
- занимаются построением тестовых БД
- Системные (system) АБД:
- отвечают за все необходимое для резервирования и восстановления данных
- контролируют производительность системы в целом
- осуществляют поиск и устранение неисправностей
- в курсе нынешних и будущих потребностей БД в плане емкости
- в курсе текущего состояния и нужд БД
- Наемныю (contract) АБД :
- приглашаются под конкретную задачу или в качестве консультантов
- передают персоналу необходимые знания
- фиксируют свои действия!
- должны прекрасно разбираться в соответствующей области
- хороши в качестве временного персонала, для оценки проекта или системы
- Администраторы-руководители :
- проводят еженедельные совещания
- определяют перечень первоочередных задач
- устанавливают и оглашают официальный курс и стратегию
- утверждают и корректируют должностные инструкции и список обязанностей
- следят за наличием соответствующей документации
Пропущен главный пункт: необходимо четко понять методологию расчета себестоимости в УПП. Курсы Фарида, консультации франчей, найм опытного внедренца УПП - неважно как, но Вы должны знать, как поменяется себестоимость продукции в зависимости от, к примеру, заполнения справочника номенклатурных групп. Пропустите этот шаг, будет иметь ОЧЕНЬ серьезные проблемы с УПП потом.Цитата:
Сообщение от Игорь Сергеевич
Разумеется, исходим из того, что у Вас есть производство, а иначе зачем Вам УПП?)
... исходим из того, что топик стартер все эти "моменты" учел ранее, сейчас он озадачен "вводом" данных в БД, которую будут "обслуживать" админы БД.Цитата:
Сообщение от Denp
;)