We are putting together a training program to get a new DBA up to speed. The assumption is that the new hire will know SQL/SSRS, but know nothing of Tessitura or the non-profit Symphony industry. Initial thoughts are a front-end to back-end approach such as: Day 1-3) Box Office training, including webinars, TClasses, working the phones, selling orders, opening and closing batches, running reports. Day 4-5) Sit with Marketing, Devo, and Finance on how they use Tessi differently than Box Office. Day 6-7) TSTATS, Wordfly Day 8) Security and consortium. Day 9-11) More webinars adn TClasses on the backend, performing simple extractions, creating lists, and learning Impresario.
Is this too aggressive? A wrong approach? I'd like to know how others have brought their DBA's up top Tessitura speed.
thanks for your thoughts!
That schedule does have a "Drinking from the fire hose" feel to it. Having said that, I wish I'd had a program like this when I first started working with the Tessitura database. I think the success of it would depend a lot on the individual involved and setting realistic expectations.
If you are able to have the DBA spend their first two weeks exclusively in training, then I think it's a great idea! However, if there are jobs that need immediate attention from the new DBA, I'd suggest stretching the training schedule out to a month or so they aren't completely overwhelmed. I think having them actually sell tickets is a great idea. I would also include gift entry and contribution acknowledgement in the training somewhere. Development data structures aren't as complex as ticketing ones. But development often has internal business practices that have quirks in them unique to the organization that won't show up in webinars or even in conversations with development folks.
Best of luck! It sounds like you will be giving your Dragon a running start.
Thank you - I appreciate the input! I can completely appreciate the fire-hose analogy. We are also looking at a more expanded training schedule that actually includes a lunch period and restroom breaks. We'll see how this GUI-to-SQL approach works and modify along the way. Thanks again!