Мабуть, вже немає людини, яка б не чула про програму 1С/BAS. І тим більше немає жодного директора, який би не розумів усіх переваг :) автоматизації обліку та звітності.
Але перед тим, як приступити до питання про те, як оцінити програміста 1С, давайте спочатку простою і зрозумілою мовою визначимо, що взагалі таке 1С:Підприємство і як це все працює.
Отже, технологічна платформа «1С:Підприємство» являє собою програмну оболонку над базою даних (СУБД). Простіше кажучи, 1С формує запити до СУБД (наприклад Microsoft SQL Server) і або щось туди пише, або читає. Власне кажучи, практично будь-який сайт робить те саме, тільки з тією різницею, що функцію 1С виконує, наприклад, PHP движок.
Технологічна платформа, у свою чергу, використовує конфігурацію, в якій описані всі дані, які необхідно зберігати, їх характеристики, а також набір процедур і функцій (це те, що відбувається після натискання «кнопочки» :)). Конфігурації бувають різні, наприклад, «Управління виробничим підприємством», їх можна змінювати, а можна створювати нові.
А тепер ми підійшли до основної частини питання, про яке чули або самі стикалися практично всі: Чому база гальмує? Ні, не так – ЧОМУ ВОНА БОЖЕВІЛЬНО ТУПИТЬ???
1-ша причина - слабке залізо сервера, на якому крутиться 1С. Якщо у Вас 2-5 користувачів, то ідеальним варіантом може виявитися не дуже потужний комп'ютер з 8 ґіґами пам'яті, двома вінчестерами (на одному стоїть windows server, на другому sql), встановленим серверним ПЗ, сервером терміналів або без (якщо Ви хочете використовувати клієнт-серверний варіант), встановленим SQL (той самий Microsoft SQL Server або аналогічний варіант від IBM, PostgreSQL, і навіть Oracle). Але якщо у Вас 30 одночасно працюючих користувачів, на день створюється близько тисячі первинних документів, Вам може знадобитися вже кілька серверів терміналів (зазвичай один користувач використовує близько напівгігабайта пам'яті), а SQL необхідно виносити на окремий сервер (а ще краще мати дзеркальний сервер з SQL), про рейди та модель відновлення теж не забуваємо.
2-га причина - надлишок інформації, яка зберігається, але не використовується, а також помилки кодування. Справа в тому, що будь-яка з типових конфігурацій намагається описати практично всі можливі бізнес-процеси, які, можливо, у Вас і не використовуються. А додатковий опис – це додаткові об'єкти метаданих (довідники, документи, регістри тощо), відповідно додаткові таблиці в SQL, що само по собі не додасть швидкості в роботі бази. Крім того, в самих об'єктах метаданих маса невикористовуваних Вами реквізитів, які зберігаються, але в них нічого не заноситься. Також, зазвичай зміни в будь-якому з документів мають на увазі рух по регістрах, а регістрів цих багато, і часто половина з них, а то й більше, ніколи не буде використовуватися у Вашому бізнесі, але інформація туди пишеться і база опухає як на дріжджах, крім того такий запис займає певний час (уявите, прописати інформацію в 2-3 регістри чи в 10?). До речі, я якось спілкувався з одним програмістом і той розповідав що в його базі, фактично, відсотків 30% бази займав лише один регістр відомостей, до якого ніхто ніколи не звертався і навіщо зберігали в ньому інформацію у вельми специфічному розрізі – не зрозуміло :). Ну а помилки кодування – це навіть не помилки, а вибір неправильних алгоритмів, виконання яких створює додаткове навантаження. Наприклад, ну не знає програміст, що таке ліве з'єднання, а масиви (таблиці) великі – ось він і намагається підставити милиці :).
3-тя причина дуже оригінальна, але не тому що рідко зустрічається, а тому що на неї не звертають уваги. Це помилки проектування бази на рівні SQL. Як правило, це і нерозуміння принципів роботи SQL в цілому, і нерозуміння окремих тонких місць в SQL. Наприклад, індексування. Варто індексувати ті записи (реквізити), які часто читаються, а не пишуться, тому що зайвий індекс займає місце (і не мало!), крім того запис інформації в індексований реквізит викликає перебудову індексу, а це вже додатковий час.
Як же оцінити програміста? В першу чергу він виразно повинен спілкуватися на вищевказані теми, висловлювати та обґрунтовувати свою думку, він повинен знати типові конфігурації (ті які у Вас використовуються), бажано мати досвід створення баз з нуля (цілком можливо, що Ви з цим зіткнетеся), добре знати мову 1С, мати досвід автоматизації, досвід вирішення нетривіальних завдань (обов'язково їх описати та розповісти як він їх вирішував з обґрунтуванням правильності рішень). Ну і по дрібницях: можливості технологічної платформи, план рахунків, запити, робота з «нерідними» SQL, використання СКД, підключення обладнання (ваги, каси, сканери). І взагалі, робити так, як потрібно, а не як простіше :).
P.S. Чомусь всі думають, що 1С - це суто бухгалтерська програма. Насправді це не так, на її основі можна поставити не тільки бухгалтерію як таку, але й створити повноцінну систему управлінського обліку та звітності конкретно під вимоги Вашого підприємства. І в ній буде все, абсолютно все.