====== IT Thinking ======

Heads of IT department may dream of the perfect team where every member can manage requests, changes and incidents in a fast and smart way by using automated scripts improving workflow quality and customers experience. Unfortunately, too many support people still make manual actions to solve issues without giving any clear risks and rollback methods.

I used to say to my team : //If you do something twice, then you should have scripted it the first time.//. Theory is so different from reality. I know very well that sometimes we don't have enough time or the appropriate knowledge at the right time to script everything.

However, if we don't make the first step, we will never go anywhere.

So let's have a look to the first step right now.

===== Theory =====

  - All requests, incidents or changes should be translated to standard input files.
  - These files should be used into a black box ((To me, a black box is a function or a set of functions which reads standard input files to create standard output files. Inputs and outputs are identified and may be used into scripts.)) to create output files summarizing the situation and testing if the request, incident or change makes sense. I call this step **preCheck** and it requires readOnly right because no modification occurs.
  - Next step consists of giving output files from **preCheck** to a second black box to execute requests or changes where **preCheck** results are accurate else they must be ignored and labelled as such. All actions applied into this **implementation** step require modification right.
  - Successful modifications are great, **postImplementation** checks are even better. How much frustrated it is to hear the sentence "//it should have worked, it did on my computer//" whereas the client has answered that it did not. It is even worse when you announced to your manager that the incident is closed whereas it is not. :-\ So, **implementation** files must be sent to a new black box to prove that all modifications have produced the expected behavior on your environment. And if some did not, then they must be identified.
  - Finally the **rollback** black box! Some people think it is optional, some others reckon it is mandatory. I would say: //without it, risk is very high//. I guess you get the workflow using input files from previous step to create new ones with results. Pay attention that if you had to rollback some modifications or even all of them, output files from **rollback** can be used as new input files for you **preCheck** step and now begin a circle! Plan makes sense.


A picture is worth a thousand words

{{ :en:thinking:blackboxthinking.png?600 |Workflow to manage requests, changes and incidents}}

{{ :en:thinking:blackboxthinking.dia |Source DIA}}

===== Example =====

Imagine, today is Monday and you start your on shift week. Your favorite IT ticketing system (ServiceNow, Jira, Octopus etc.) is waiting for you. The first ticket you opened requests you to modify AD users because some names are misspelled.

Action plan :

==== preCheck ====


  * Our first black box needs at least one input file which summarizes the request. Luckily, there is one CSV file into the ticket with all modifications the client requested. It looks like this :

<csv>
Name,Login,Email,Tel
Jean Robert,jrobert,jrobert@company.com,123456
Marie Curie,mcurie,m_curie@company.com,456789
Calamity Jane,calamity,cjane@company.com,789123
</csv>

This is a perfect input file for a preCheck function. Now we must wonder : what do we want to check ?
  - For each line:
    - Is a real active AD User ?
    - Are we sure that the AD User is the good one ?

Since we detected two checks, we are going to add two new columns to our output file: **AdActiveUser** and **MailMatch**.

Let's do it in [[en:powershell:advanced|Powershell]] for example.

This first function provides us a new file that we are going to use for the **implementation** step.

==== Implementation ====

PreCheck provides us this new file.

<csv>
Name,Login,Email,Tel,AdActiveUser,MailMatch
Jean Robert,jrobert,jrobert@company.com,123456,yes,yes
Marie Curie,mcurie,m_curie@company.com,456789,yes,no
Calamity Jane,calamity,cjane@company.com,789123,no,no
</csv>