Як зрозуміти, що людина знає свою справу?


 Напевно, немає людини, яка б не чула про програму 1С. І тим більше немає ні одного директора, який би не розумів всіх принад автоматизації обліку та звітності.

 Але перед тим, як приступити до питання про те, як оцінити програміста 1С, давайте спочатку простим і зрозумілим мовою визначимо, що таке взагалі 1С:Підприємство і як це все працює.

 Отже, технологічна платформа «1С:Підприємство» являє собою програмну оболонку над базою даних (СУБД). Простіше кажучи, 1С формує запити до СУБД (наприклад Microsoft SQL Server) і щось там пише або читає. Власне кажучи, практично будь-який сайт робить те ж саме, тільки з тією різницею, що функцію 1С виконує, наприклад, PHP движок.

 Технологічна платформа, в свою чергу, використовує конфігурацію, в якій описані всі дані, які необхідно зберігати, їх характеристики, а також набір процедур і функцій (це те, що відбувається після натискання «кнопочки»J). Конфігурації бувають різні, наприклад, «Управління виробничим підприємством», їх можна змінювати, а можна створювати нові.

 А тепер ми підійшли до основної частини питання, про яке чули або самі стикалися практично все: Чому база гальмує? Ні, не так - ЧОМУ ВОНА ШАЛЕНО ТУПИТЬ???

 1-ша причина - слабке залізо сервера, на якому крутиться 1С. Якщо у Вас 2-5 користувачів, то ідеальним варіантом може виявитися не дуже потужний комп'ютер з 8 гигами пам'яті, двома венчестерами (на одному стоїть windows server, на другому sql), встановленим серверним ПЗ, сервер терміналів або без (якщо Ви хочете використовувати клієнт-серверний варіант), SQL (той же Microsoft SQL Server або аналогічний варіант від IBM, PostgreSQL, і навіть Oracle). Але якщо у Вас 30 одночасно працюючих користувачів, в день створюється близько тисячі первинних документів, Вам може знадобитися вже кілька серверів терміналів (зазвичай один користувач використовує близько полугигабайта пам'яті), а SQL необхідно виносити на окремий сервер (а ще краще мати дзеркальний сервер SQL), про рейди та відновлення модель теж не забуваємо.

 2-га причина - надлишок зберігається, але не використовуваної інформації, а також помилки кодування. Справа в тому, що будь-яка з типових конфігурацій намагається описати практично всі можливі бізнес-процеси, які, можливо, у Вас і не використовуються. А додатковий опис - це додаткові об'єкти метаданих (довідники, документи, регістри тощо), відповідно додаткові таблиці в SQL, що саме по собі не додасть швидкості в роботі бази. Крім того в самих об'єктах метаданих маса невикористаних Вами реквізитів, які зберігаються, але у них нічого не заноситься. Також, звичайно зміни в будь-якому з документів передбачає рух по регістрах, а регістрів цих багато, і найчастіше половина з них, а то й більше, ніколи не буде використовуватися у Вашому бізнесі, але інформація туди пишеться і база пухне як на дріжджах, крім того така запис займає певний час (уявіть, прописати інформацію в 2-3 регістра або 10?). До речі, я спілкувався з одним програмістом і той розповідав що в його базі, фактично, відсотків 30% бази обіймав всього лише один регістр відомостей, до якого ніхто ніколи не звертався і навіщо зберігали в ньому інформацію в досить специфічному розрізі - не понятноJ. Ну а помилки кодування - це навіть не помилки, а вибір неправильних алгоритмів виконання яких створює додаткове навантаження. Наприклад, ну не програміст знає, що таке ліве з'єднання, а масиви (таблиці) великі - ось він і намагається підставити костылиJ.

 3-тя причина дуже оригінальна, але не тому що рідко зустрічається, а тому що на неї не звертають увагу. Це помилки проектування бази на рівні SQL. Як правило це і нерозуміння принципів роботи SQL в цілому і нерозуміння окремих тонких місць в SQL. Наприклад, індексування. Варто індексувати ті записи (реквізити), які часто читаються, а не пишуться, бо зайвий індекс займає місце (і не мало!), крім того запис інформації в індексований реквізит викликає перебудову індексу, а це вже додатковий час.

 Як же оцінити програміста? В першу чергу він виразно повинен спілкуватися на вищевказані теми, висловлювати та обґрунтовувати свою думку, він повинен знати типові конфігурації (ті які у Вас використовуються), бажано мати досвід створення баз з нуля (цілком можливо, що Ви зіткнетеся з цим), добре знати мову 1С, мати досвід автоматизації, досвід вирішення нетривіальних завдань (обов'язково їх описати і розповісти, як він їх вирішував з обґрунтування правильності рішень). Ну і по дрібниці: можливості технологічної платформи, план рахунків, запити, робота з «нерідними» SQL, використання СКД, підключення обладнання (ваги, каси, сканери). І взагалі, робити так, як потрібно, а не як прощеJ.

 P.S. Чомусь всі думають, що 1С - це суто бухгалтерська програма. Насправді це не так, на її основі можна поставити не тільки бухгалтерію як таку, але й створити повноцінну систему управлінського обліку і звітності конкретно під потреби Вашого підприємства. І в ній буде все, абсолютно все.

Консультант з впровадження 1С

УКРАЇНА
61000 м. Харків, пл. Повстання 7/8, 
  +38(050)978-88-74
  +38(057)761-99-01
   Ця електронна адреса захищена від спам-ботів. вам потрібно увімкнути JavaScript, щоб побачити її.

Консультант з обслуговування 1С

УКРАЇНА
61000 м. Харків, пл. Повстання 7/8, 
  +38(066)131-75-25
  +38(057)761-99-01
   Ця електронна адреса захищена від спам-ботів. вам потрібно увімкнути JavaScript, щоб побачити її.