Many times, how to do something is well documented. Instructions for recipes, for directions, for medicines – they are everywhere. Recipes – what is needed for cake, how much to add, how long to bake, what temperature the oven; directions – where to turn, how far to travel a street or highway; medicines – what years qualify, what dosage to take, how often to take, when you should stop. In many cases, we already know – as the process involved has not changed. We check the instructions – they are the same.
IT systems however, they change – and change often! And the more complicated the system the more changes involved, the more people and users are affected and the more dominoes are ready to fall if everything is not handled properly. Most learn as the mistakes happen, remember their mistakes, and correct themselves on each repeating event. BUT – what happens when that person leaves the company and goes elsewhere? Without documentation, if a transition process occurs then the transfer of the tasks, knowledge and processes from the person leaving to someone in leadership or to the replacement person will still have voids from missed items, misunderstandings and questions not asked (because at the time, there was not something that raised a question).
Now, this is only for one person – imagine an entire company changing from an internal IT department to outsourcing, that is – having another company manage and own the operations, security, upgrades, version control, change management, business processes, data flow, and everything else involved with an IT system. For most modules within the system, any customizations and associated business processes will not be too difficult to ascertain and master. However, in every system, whether Oracle, SAP, PeopleSoft or any other medium to enterprise level relational database system, the HRIS modules are extremely complex, detailed and full of caveats. The data flow and business processes within the HRIS systems is similar to dominoes. If not setup properly or used properly, then the uses will witness of dominoes they will never forget. Some missteps can be easily corrected, other missteps will result in data that can be seen by some people but not all the people that should see their information, and other steps – as has been experienced recently by one of my clients – will bring the entire system down and will require a complete restoration.
In the days of past, many people stayed with a company 20, 30, 40, or more, years (in the USA, the retirement age – though not mandatory – is 65; in other countries, the retirement age is earlier). Most people in the days of the past would work 50 years before they retired, while working for anywhere from one to 5 companies. Today, many people will work for 5 companies before they complete their first 25 years of work. Along with this change has been the complexity of the work – and when a person leaves a company, usually most of what they have learned and know goes with them. Some will remain behind with the company not enough to make the transition from the person leaving to the replacement person go very smoothly. Again, change all this from an internal IT system – including HRIS – to outsourcing these services.
In a change from an internal service to a third-party service – or outsourcing – everything that was not clearly documented, even why things were decided, becomes magnified. In many cases this results in a lot of “bad-blood” in the relationship between the company that is outsourcing and the company hired as the outsource.
Though not the perfect answer to this dilemma, it still goes a long way in resolving many problems: DOCUMENTATION. Everything — and I mean E-V-E-R-Y-T-H-I-N-G – should be documented with the business processes used to maintain the flow of data, tasks, and decisions. The biggest EXCUSE I hear for not doing this is there is not enough time to do this. My response is always, “You may not have the time but you always seem to have the money to do it incorrectly.” There are MANY studies on how much it costs to correct an error – example: ONE paycheck generated incorrectly can cost as much s US$75 to correct, but usually near US$50 – that is PER CHECK. If a deduction has gone uncorrected for several paychecks, the cost is more. Why such a cost? Well first, the computer does only what it is told – it is like a very well trained dog doing ONLY what it was trained to do. You train it incorrectly, it does it incorrectly. Next, someone has to determine what should have happened and correct the system, doubling – or more – the work to product the one paycheck. Then, if there were taxation issues involved, or vendors involved, corrections need to be sent to the agencies and companies. Hopefully, they will apply it properly to their records – if they don’t, then the company and the agency or vendor have to work out why the correction failed. Time usually involved in a correction? For the company? Could be as much as 2 hours. For the agencies or vendors? Add another hour. Remember, this is for ONE paycheck. The economies-to-scale does kick-in when there are multiple errors, but the cost to correct does not decrease either.
Detailed documentation will go a long way in resolving much of the problems as well as keep as many dominoes from falling. In theory, when a person leaves the company, the replacement person who is familiar with the system should be able to sit down and perform most of the tasks without needing to ask too many questions – IN THEORY. And as we all know, theory and the real world always like to collide… As a result we are always struggling with managing and correcting the IT system. This includes version control, change management, daily tasks, and system operations.
But the long-term effects of detailed documentation has shown its return in multiple folds – and has allowed the company to focus on what they should be doing in the first place – building and managing their business instead of their system managing and frustrating them.
Garrett O'Brien é consultado por implementações SIRH pelas empresas e as empresas (Fortune 100, 500 e 1000) desde 1991. Seus clientes anteriores incluem Lubrizol, ADP, Case New Holland, a Cushman & Wakefield, MAHLE, Honeywell International, Sodexho, e muitos outros localizados em os EUA Garrett é • Editor e escritor de 4 blogs mundiais focada em SIRH e gerenciamento de projetos, que são lidos em 160+ países • Exec VP para EUA CGServices enfocando multi-fornecedor, o sistema de multi-linha para sistemas HRIS • membro do Conselho de Gerson Lehrman Group Conselho, o que ajuda a instituições dos líderes mundiais se reunirem, engajar e gerenciar os especialistas em uma ampla gama de setores e disciplinas. Garrett se concentra em SIRH global Garrett está trabalhando em alguns projetos em Brasil. Um deles é focando as melhorias necessárias na gestão de projetos, especialmente as fases mais iniciais. O outro projeto se concentra no uso de tecnologia dentro do sistema de ensino para melhorar a educação de tecnologia para estudantes e professores. Ambos os projetos serão locais no Brasil, mas será global em perspectiva. Atualmente, o Sr. O'Brien reside em o estado de São Paulo e funciona a partir de Home Office. Não hesite em contactar-lo diretamente no LinkedIn (www.linkedin.com/in/garrettobrien/pt) ou por e-mail (gobrien@thehrisworld.com) twitter: @thehrisworld @hriscareerworld @thw_research @thwrn_news
You must be logged in to post a comment.
8:29:48 am
Garret, could not agree more with your article. I have seen large companies building systems without properly documenting them (cutting costs) or without any documentation at all. Some times IT staff at these organisation use this strategy as a form of power/control, they control the knowledge, so they are “needed” by the organisation.
In recent years I have seen another thing happening at some of the clients I have done work. Using the umbrella of AGILE development, they start to develop without properly design, analyse or document what is being developed. Agile implies an iterative and light developing process, but by any means should result in lack of planning, designing and documenting.
No documentation means loss somewhere in near future for the organisations who behave like this.
Great article,
Pedro Oliveira
Senior Software Architect
9:14:42 pm
Obrigado Pedro
Não há valor a ser encontrado em saber o que já foi tentado e falhado – e que foi bem sucedido.
Com a saída de trabalhadores experientes que foram bem sucedidos em ganhar as maneiras eficientes, vai assim os meios e conhecimentos para manter essa eficiência.
A sabedoria não é adquirida de uma falta de conhecimento, nem por tendências que não duram. Foram em TI há mais de 30 anos se e tenho visto muitos desses desenvolvimentos – como AGILE – vêm e vão. O que corrige algo a curto prazo não significa necessariamente uma solução a longo prazo tem sido adquirida.
Sendo um estudante da história do mundo, é interessante ver as semelhanças nos negócios e países. Você consegue imaginar um governo militar ou abandono de documentação e próspera? No entanto, muitas empresas acreditam que podem fazer sem …
Para os vencedores vão a estraga 🙂
11:43:16 am
Vou discordar do Mr. O´Brien e tb do Sr. Oliveira, do 1º comentário no seguinte ponto: Uma documentação “burrocrática” não serve para nada, não importando se TI, Serviço Médico, Business Process etc. Porque será outra pessoa que lerá, que chegará com outras vivências e bagagens culturais (os tais certos e errados que cada um temos) e, realmente, sem falta de tempo para a tomada de decisão, se é que o(a) chefe deixa.
Que tal os profissionais de TI – sou oriundo dessa área – pensarem e inovarem não em redação de documentos mas em registro em vídeo, áudio tal qual fazem centenas (ainda) de empresas. Esse é um dos motivos que discordo dos usos indiscriminados dos ITILs e PMIs pois burrocratizaram – e ganham muito dinheiro com isso – os projetos para nada ou para CIO falar que tem. Quanto ao desenvolvimento ágil, vale refletir por que ele surgiu? Não seria por causa de velhos paradigmas de profissionais de TI? Gosto muito do #omundomudou senhores.
Sugiro visitar o site e ler o livro Getting Real, da 37signals para esses novos tempos. abs, @grillojotae
9:15:15 pm
José
Aqui temos uma expressão, talvez você já ouviu falar…
Não é fácil ensinar um cão velho truques novos.
Por que eu digo…
Você deve tentar ensinar os cães velhos truques novos!
Aqueles que não conhecem a história estão destinados a repetir os mesmos erros.
Embora você compartilha seus sentimentos para não documentar, você não fornecer comprovação de suas opiniões. Isso eu adoraria ver e incentivar. Um debate vivo sempre abraço.
Se há uma coisa que eu aprendi sobre os novos tempos? São tendências que se desvanecem e voltar ao experimentado e testado.
3:58:49 pm
Olá, Garret,
Realmente não tenho nenhum exemplo de documentação inovadora de projetos de TI para compartilhar. Tenho sim uma visão crítica de que a documentação convencional tem pouca utilidade, ainda mais na velocidade de mudanças que estamos vivendo, ou seja, descartamos – com uma migração eficiente de dados – sistemas legados pois estão se tornando cada vez mais caros suas manutenções e sua documentação em algum armário ou inacessível em algum diretório do servidor corporativo. Me baseio muito nos vídeos de treinamento das forças públicas – bombeiros, policiais, equipes de resgate que utilizam de meios multimídia para corrigirem e aprenderem com os erros e os acertos. Não considero esses recursos tendências que desvanecem ao longo do tempo. No Brasil, temos uma tradição oral mas não mediática para inovarmos nessa área. Infelizmente importamos modelos. Acho apropriado a expressão: Não use velhos mapas para descobrir novos mundos. um abraço.
5:02:22 pm
Será que tenho que discordar José, embora eu aprecio a sua resposta.
Antigos mapas ou ferramentas de navegação ruim ??… os mapas já foram testados. Com a introdução de “novos mapas”, apenas indícios de uma modificação do “velho” – as sementes e genética dos “mapas” anterior e antes ainda estão na “novos mapas”.
O que mudou? Normalmente, os métodos para aumentar a oferta – mas sempre com um custo, muitas vezes comprometendo a eficiência que efetivamente atrasar o retorno do investimento. Por quê? Executivos e gestão deslocar seu foco longe de retorno do investimento ao custo de projeto.
Com mais de 29 implementações, vi isso acontecer muitas vezes – só no final que o cliente percebe seu erro, e reconhecer que eles tentaram reinventar a roda.
Enquanto isso, eles têm conhecimento de sair pela porta que só pode ganhar mais uma empresa – se ouvem …
10:11:14 am
Olá Garret, concordo contigo que os antigos mapas já foram testados. E foram úteis para aquele momento, aquele instante. Não digo todos os mapas mas será que alguns ainda – da maneira padrão que sempre foram utilizados – agregam realmente valor para os negócios? O mundo muda cada vez mais rápido e não é só na tecnologia não. Assim, hj aprendemos mais retomando conceitos de biologia mesclando-os com os conceitos de gestão, devido a necessidade de uma multidisciplinaridade somente possível nos dias e nos ambientes atuais. Parabenizo-o pelas 29 implantações e espero felicitá-lo na próxima, que com certeza, terá uma inovação agregada dado que as implantações anteriores tiveram seu tempo, espaço e valor no passado. Ah, não consegui interpretar o último parágrafo. Estou gostando da conversa. um abraço