At the beginning of the SAP implementation project, it was identified that one of the key drivers was to improve efficiency. We had a large number of systems, none of which talked to each, and as a result, a large number of staff were involved in just manipulating data. It made sense to try to get all of the data in a single system so that it would be easier to work with - and don't say this too loudly, but it was felt that we could perhaps reduce headcount by being more efficient.
We were told that it was possible to improve processes by using the various processes that were built into the SAP software. A number of key areas were identified and we looked forward to seeing these in action. However, in most of those areas, we have still yet to see any significant improvement. In some cases, we have had to take on a couple of staff as the process is now a bit more complex than before.
However, there is an area where we have seen some spectacular improvements - the funny thing is that it was completely unexpected. It has made a major difference to many departments, has saved hours of work every week, reduced waste and saved a sizable amount of money.
When I first joined the comapny, I discussed the concept of electronic document management - at that time, everything was paper based. It was decided that it was not practical, and when we started work on SAP, it was not even put on the blueprint. Having talked to one of the consultants, he did some work for us to set it up, and I bought and installed some hardware to allow staff to scan all incoming documents.
To begin with, there were a few teething issues - getting people to understand where the files were being scanned to was the biggest, and then getting these attached to the relevant item within SAP. But within a fairly short time period, almost everyone was getting to grips with the system.
To explain in more detail, let's look at the sales office. They process around 1,000 orders a week - and every day without fail, they will get a number of queries about an order that has been placed. In the past, this caused some considerable work - although they had access to the data entered, people would question if the order had been entered correctly. The staff member would have to take the customer's details, then hang up, and go look for the original documentation.
As this was not a key driver, we don't have hard evidence of the time taken to recover the paper files, but it is generally accepted that it would normally take between 15 and 30 minutes for each order. (Some would take longer, particularly if the file was misplaced). The staff member would then have to call the customer back wasting more time - and of course, it caused some frustration with the clients.
Now, if someone queries an order, the sales person can click on a link and the scanned file opens up in a matter of seconds. I don't use it that regularly, but I can find and open an order, and then the scanned file in about 40 seconds - the sales staff can do it in just over half that time. And it is not just the sales office that benefits from this - purchasing, accounts, distribution are all making good use of this facility. In fact, we estimate that we are saving the time equivalent of between 4 and 5 full time staff each and every week with the document management system. (My colleagues agree that is a conservative estimate.) We think that as we roll it out to other sites, the savings could be as much as 20 full time staff.
Now don't get me wrong, we are not going to be laying staff off any time soon - but the time saved is going to allow us to do more things that we need to. Sales can do a bit more cold calling, a bit more customer relationship management etc. Some of the saved time will be used to make sure that they have more time to concentrate on other areas where they are not so confident.
I had a comment from one of the staff the other day - she said that the document management system on its own was almost worth the effort of the SAP implementation. Well, I'm not sure that I would totally agree as the cost has been so high. But it is an area that we can point to, in order to highlight success in the project, and as my old football coach used to say "a win is a win".
Now a lot of people within IT will say that this should not be such a surprise - electronic document mangement has been around for many years, and the benefits are well known and fully documented. But you have to understand that for our company, this is a completely new way of working - and one that took a bit of effort to get people to use in the initial stages.
If staff get excited about it because they can now see some tangible benefits, then that is a good thing (a really good thing!). We can then try to use that to get them on board with other aspects of the SAP system. If one area of the system makes their jobs easier, then maybe we can encourage them to be more positive about the rest of the system - and who knows, maybe we will eventually be able to say with hand on heart that the project was worthwhile. We may even see a return on our investment!
Saturday, 24 July 2010
Sunday, 18 July 2010
Trouble with training
When I was still in high school, I had an English teacher for a year, who told me something that I still remember - "Learning is a science; but teaching is an art". At the time, I didn't fully understand what he meant, but over the years, I have come to see that this is actually a very profound statement.
Since college, I have worked hard to keep my skills up to date. I've read technical material, books and white papers, many of which I have kept - and these have sections highlighted or pages marked out with colored tabs. I scribble comments in the margins, and occasionally use post-it notes as well. I use a structured method to read, digest and understand the various items, and it is clear that this is a scientific approach to gaining knowledge. For me, this is the best way to learn new things - altho I always then want to try to apply what I have learned in a test environment.
However, this method doesn't suit everyone. Altho I am happy to spend my own time wading thru various documents, most of my colleagues are not so eager. They leave work at the end of the day, and don't really want to spend their leisure time on what they see as "work related" tasks. Having said that, they are also not too keen to spend much of their working day reading books. At the beginning of the project, we bought a number of the SAP Press books (and some others) which were handed out to the relevant department heads - many of these books were opened once, a few pages looked at, then closed, and they have remained that way since.
The reality is that not everyone is comfortable with self-learning material - they find it difficult to motivate themselves to work their way thru the material, and have difficulty in relating what they read to the work that they do. This is an issue that affects a lot of the training that we carry out, not just SAP - and this is where the teaching "art" comes in. It is necessary for the tutor to understand that each person is different and requires different methods to learn - and the teacher has to have a streak of creativity that allows them to develop ways of presenting the material that will get thru to the student.
During the project, the various project leaders were encouraged to create self-study items to be used by the staff. These were generally involving a single process or part of process - for example, "how to create a sales order" or "how to release a purchase order". I setup a shared repository for these files, and access permission was given to all staff to read and a few more senior people to change or replace, so that they could go thru the files, make whatever changes were felt appropriate to make the materal as relevant as possible.
Unfortunately, it appears that none of the staff actually use this material. Altho it has been specifically aimed at providing them with the right information, and they have all been reminded of where to find it, no-one actually makes any use it at all. It seems that the concept of learning by reading is totally alien to them and that doesn't look as if it is going to change any time soon.
When I first joined the company, I expressed my concern at what I saw a very low level of IT literacy amonsgt staff. People had learnt by rote - "press button 3, press button A, press F7". They had no idea of what these keystrokes did, or why they had to press them - they just knew that was the sequence.
In many cases, altho they were carefully trained to use other equipment, or given instruction in safety procedures, they had received little or no training on how to do the specific task on the computer. At best, someone else that just knew the sequence without understanding why would pass on that information, often by writing it down on a sticky note which was then pasted on the monitor.
Senior management were not particularly bothered - they didn't see the need for staff to be "IT Trained" as they put it. I can understand that there is a limit, but I do feel that a lot of problems are caused by inadequate training, and these create problems, delay work and all of this will actually end up wasting money.
With the SAP project, I had hoped that we move away from this attitude and be able to get people properly trained. The problem is of course that if people don't have the right motivation, then it is unlikely that they will improve their skills. If we can't improve work practices, then we will never get the full value out of the SAP project. I therefore suggested that we needed to have a properly dedicated training facility.
So we set-up a fully equipped training room for IT - this is available for everyone to use and there was some good use made of it before the go-live. However, since then it hasn't been used once. I think that this is a shame as it could help us get more out our investment. But with so few people having the self-motivation to learn new stuff and the discipline to stick with it, I suspect that we will not see the value that we should.
Ultimately, we need to change people's perceptions - it is just no longer good enough for someone to know the sequence of key strokes, they need to understand the process and why they have to follow it.
Since college, I have worked hard to keep my skills up to date. I've read technical material, books and white papers, many of which I have kept - and these have sections highlighted or pages marked out with colored tabs. I scribble comments in the margins, and occasionally use post-it notes as well. I use a structured method to read, digest and understand the various items, and it is clear that this is a scientific approach to gaining knowledge. For me, this is the best way to learn new things - altho I always then want to try to apply what I have learned in a test environment.
However, this method doesn't suit everyone. Altho I am happy to spend my own time wading thru various documents, most of my colleagues are not so eager. They leave work at the end of the day, and don't really want to spend their leisure time on what they see as "work related" tasks. Having said that, they are also not too keen to spend much of their working day reading books. At the beginning of the project, we bought a number of the SAP Press books (and some others) which were handed out to the relevant department heads - many of these books were opened once, a few pages looked at, then closed, and they have remained that way since.
The reality is that not everyone is comfortable with self-learning material - they find it difficult to motivate themselves to work their way thru the material, and have difficulty in relating what they read to the work that they do. This is an issue that affects a lot of the training that we carry out, not just SAP - and this is where the teaching "art" comes in. It is necessary for the tutor to understand that each person is different and requires different methods to learn - and the teacher has to have a streak of creativity that allows them to develop ways of presenting the material that will get thru to the student.
During the project, the various project leaders were encouraged to create self-study items to be used by the staff. These were generally involving a single process or part of process - for example, "how to create a sales order" or "how to release a purchase order". I setup a shared repository for these files, and access permission was given to all staff to read and a few more senior people to change or replace, so that they could go thru the files, make whatever changes were felt appropriate to make the materal as relevant as possible.
Unfortunately, it appears that none of the staff actually use this material. Altho it has been specifically aimed at providing them with the right information, and they have all been reminded of where to find it, no-one actually makes any use it at all. It seems that the concept of learning by reading is totally alien to them and that doesn't look as if it is going to change any time soon.
When I first joined the company, I expressed my concern at what I saw a very low level of IT literacy amonsgt staff. People had learnt by rote - "press button 3, press button A, press F7". They had no idea of what these keystrokes did, or why they had to press them - they just knew that was the sequence.
In many cases, altho they were carefully trained to use other equipment, or given instruction in safety procedures, they had received little or no training on how to do the specific task on the computer. At best, someone else that just knew the sequence without understanding why would pass on that information, often by writing it down on a sticky note which was then pasted on the monitor.
Senior management were not particularly bothered - they didn't see the need for staff to be "IT Trained" as they put it. I can understand that there is a limit, but I do feel that a lot of problems are caused by inadequate training, and these create problems, delay work and all of this will actually end up wasting money.
With the SAP project, I had hoped that we move away from this attitude and be able to get people properly trained. The problem is of course that if people don't have the right motivation, then it is unlikely that they will improve their skills. If we can't improve work practices, then we will never get the full value out of the SAP project. I therefore suggested that we needed to have a properly dedicated training facility.
So we set-up a fully equipped training room for IT - this is available for everyone to use and there was some good use made of it before the go-live. However, since then it hasn't been used once. I think that this is a shame as it could help us get more out our investment. But with so few people having the self-motivation to learn new stuff and the discipline to stick with it, I suspect that we will not see the value that we should.
Ultimately, we need to change people's perceptions - it is just no longer good enough for someone to know the sequence of key strokes, they need to understand the process and why they have to follow it.
Sunday, 11 July 2010
Practice what you preach
Over the years, SAP has worked with a lot of companies in different industries - they have seen many different ways of working, and various people have developed parts of the program to modify it, to allow better integration with the business processes of those organisations. When a vendor then sells SAP to a new customer, they then promote these as "best practices" and suggest that if the more successful companies (using SAP) use them, then it makes sense for the newer purchasers of SAP to use them as well if they wish to be equally successful.
I'm not sure that I fully endorse this idea - just because a successful business uses a particular process does not mean automatically that process will work elesewhere, or that it is the best way to do something. I've seen many different organisations and ways of working - each had their own methods of doing things and in most cases, they worked really well. However, I am prepared to keep an open mind on the topic.
I understand the concept of challenging existing practices, and agree that sometimes a business can get stuck with doing something a particular way because "that's how we've always done it". My own company had exactly this issue (and in some areas, I think that we are still suffering the same problem) and it makes sense to use the implementation project as an opportunity to examine what we do and try to find more efficient methods of working.
As it happens, I believe that this is a process that should never end. People should be encouraged to try to find better ways of doing things and as this does not always come naturally, it may be necessary to undertake appropriate training. I spoke to several of the consultants working on our project, and what became clear was that none of their people have attended any official SAP training sessions or seminars in the last 5 years. This would raise the question if the "best practices" that they are advising us to follow are actually the most appropriate or up to date.
However, I believe that the "best practices" are not just about the processes that are used within the normal business flow. I'm sure that some of the more seasoned SAP people that follow this blog will correct me if I am wrong, but it seems to me that the "best practices" should also include the way that the SAP system is structured and managed. In particular, such elements as change management & testing are crucial and it is vital that correct procedures are followed to ensure that when development work is undertaken, it does not cause problems to the operations of the organisation.
I have to admit to being very concerned about the way that our consultants seem to ignore the practices that SAP promote in this area. As an example, shortly after go live, our internal project manager highlighted that we still needed a particular report (one that had been requested way back). One of the consultants worked on this and in due course, I received an email to request that certain staff should be given access to a new transaction that had been created from an existing one. But when I tried to do this in the golden list, the transaction simply did not exist. It turned out that he had unlocked the production client and created the new transaction - then locked the client, instead of creating it in the development system and transporting it in the approved manner.
I queried this in an email, and received no reply - I'm told that when the consultant concerned was questioned about it, he became angry and told the project manager that I was being unhelpful. I subsequently found that he then unlocked the production client again, and added the transaction to some roles, before locking it down. That worked fine for a couple of days, but after I had carried out another transport of roles between the systems for another update, the transaction was again not available.
Of course, he then did the work in the correct way (although I note that the transaction is slightly different in the production system to the one in development and test systems). But it seems strange that he wouldn't use the correct procedure to begin with - he should have known what would happen. I regret to say that this is not an isolated incident, and there have been several other similar issues with work not being done according to SAP's own guidance.
Another area of contention relates to testing of development work - or rather the non-testing of development work. Checking in the transport system, I see that one particular item was transported from development system to production system a dozen times in the space of an hour. It's clear that the consultant was not bothering to check anything in the development or test systems, but simply making a change, transporting it and testing in the production system.
What worries me a bit is that the project team have been working with the consultants, so they have seen these unsatisfactory processes and seen them as normal. If I suggest that doing something a particular way is not appropriate, they immediately point to the consultants and indicate that is the way that they do things.
So does it really matter if people don't quite follow this "best practice"? I would suggest that yes it does - SAP is a large, complex, inter-related piece of software. The procedures are there for a reason, to ensure that the changes that are required are working appropriately and do not cause issues elesewhere. If people don't follow the procedures, then things can go wrong, and putting them right can be a huge undertaking.
What is worse, if someone gets used to doing something in a particular way (even if it is wrong), then it is hard to get them to change. And this of course then brings us back to the beginning - we have replaced one set of practices with another, but neither of these are "good practices" and I seriously doubt that we could define them as "best practices".
But perhaps that is just me - it could be that I am making a mountain out of a molehill. These issues are causing the IT staff work, and we seem to spend time on dealing with what I see as unnecessary corrections rather than what I feel we should be doing, which is the more proactive work to maintain systems. However, we are coping, so maybe things are not so bad after all.
I'm not sure that I fully endorse this idea - just because a successful business uses a particular process does not mean automatically that process will work elesewhere, or that it is the best way to do something. I've seen many different organisations and ways of working - each had their own methods of doing things and in most cases, they worked really well. However, I am prepared to keep an open mind on the topic.
I understand the concept of challenging existing practices, and agree that sometimes a business can get stuck with doing something a particular way because "that's how we've always done it". My own company had exactly this issue (and in some areas, I think that we are still suffering the same problem) and it makes sense to use the implementation project as an opportunity to examine what we do and try to find more efficient methods of working.
As it happens, I believe that this is a process that should never end. People should be encouraged to try to find better ways of doing things and as this does not always come naturally, it may be necessary to undertake appropriate training. I spoke to several of the consultants working on our project, and what became clear was that none of their people have attended any official SAP training sessions or seminars in the last 5 years. This would raise the question if the "best practices" that they are advising us to follow are actually the most appropriate or up to date.
However, I believe that the "best practices" are not just about the processes that are used within the normal business flow. I'm sure that some of the more seasoned SAP people that follow this blog will correct me if I am wrong, but it seems to me that the "best practices" should also include the way that the SAP system is structured and managed. In particular, such elements as change management & testing are crucial and it is vital that correct procedures are followed to ensure that when development work is undertaken, it does not cause problems to the operations of the organisation.
I have to admit to being very concerned about the way that our consultants seem to ignore the practices that SAP promote in this area. As an example, shortly after go live, our internal project manager highlighted that we still needed a particular report (one that had been requested way back). One of the consultants worked on this and in due course, I received an email to request that certain staff should be given access to a new transaction that had been created from an existing one. But when I tried to do this in the golden list, the transaction simply did not exist. It turned out that he had unlocked the production client and created the new transaction - then locked the client, instead of creating it in the development system and transporting it in the approved manner.
I queried this in an email, and received no reply - I'm told that when the consultant concerned was questioned about it, he became angry and told the project manager that I was being unhelpful. I subsequently found that he then unlocked the production client again, and added the transaction to some roles, before locking it down. That worked fine for a couple of days, but after I had carried out another transport of roles between the systems for another update, the transaction was again not available.
Of course, he then did the work in the correct way (although I note that the transaction is slightly different in the production system to the one in development and test systems). But it seems strange that he wouldn't use the correct procedure to begin with - he should have known what would happen. I regret to say that this is not an isolated incident, and there have been several other similar issues with work not being done according to SAP's own guidance.
Another area of contention relates to testing of development work - or rather the non-testing of development work. Checking in the transport system, I see that one particular item was transported from development system to production system a dozen times in the space of an hour. It's clear that the consultant was not bothering to check anything in the development or test systems, but simply making a change, transporting it and testing in the production system.
What worries me a bit is that the project team have been working with the consultants, so they have seen these unsatisfactory processes and seen them as normal. If I suggest that doing something a particular way is not appropriate, they immediately point to the consultants and indicate that is the way that they do things.
So does it really matter if people don't quite follow this "best practice"? I would suggest that yes it does - SAP is a large, complex, inter-related piece of software. The procedures are there for a reason, to ensure that the changes that are required are working appropriately and do not cause issues elesewhere. If people don't follow the procedures, then things can go wrong, and putting them right can be a huge undertaking.
What is worse, if someone gets used to doing something in a particular way (even if it is wrong), then it is hard to get them to change. And this of course then brings us back to the beginning - we have replaced one set of practices with another, but neither of these are "good practices" and I seriously doubt that we could define them as "best practices".
But perhaps that is just me - it could be that I am making a mountain out of a molehill. These issues are causing the IT staff work, and we seem to spend time on dealing with what I see as unnecessary corrections rather than what I feel we should be doing, which is the more proactive work to maintain systems. However, we are coping, so maybe things are not so bad after all.
Friday, 2 July 2010
Confidence vs Arrogance
I like to think that I am pretty confident, and generally for a good reason. Over the years, I've proven my skills many times - I've managed my teams, my budgets, some big projects and delivered real measurable benefits to the various companies that I have worked for. When I am in a particularly good mood, you may hear me say that I can fix anything, given the time and resources.
In fact, at one previous position, I was known as the "go-to guy" - if they had an issue, the first name that came up was mine. Where was I. what was I doing, could I be moved to take care of the problem. My direct manager loved to use football metaphors -he told me that whenever someone fumbled the ball, they looked to me to pick it up and run with it.
Having said that, I recognise that I don't always know the answer. Sometimes, it is necessary to fully analyse a problem, and look at alternative answers before choosing a course of action. It's often necessary to look to other people for advice and support - and sometimes even relatively junior members of staff can have good ideas. It's foolish to ignore these just because of the status of the person, but a lot of people will do just that. And I'm more than happy to accept that I've made a few bad decisions at times - but I always try to learn from these so that I can prevent them being made again.
The problem is that sometimes, confidence can cross the line into arrogance. I would suggest that a couple of our consultants have crossed that line - and one guy in particular stands out.
When we first started the project, some 3 years ago, we were given a series of resumes of the people that would be working on the project with us from the consultancy. These looked really good, with a group of people that had all had at least 6 projects and and an average of 8 years working with SAP.
Unfortunately, none of these people were ever "available" to actually work on our project, so we had a group of people that we knew little about. What became clear was that in most cases, they had limited experience - an average of 2 or 3 projects with at most a couple of years experience.
However, the one particular guy was uber confident - if you listened to him, he had almost 20 years experience of SAP and had worked on literally dozens of projects. He certainly seemed to be the one that the others looked to for advice whatever the problem.
As it happens, I met someone that knows this guy from a previous implementation. It turns out that he actually only has had coming up for 6 years experience, and our project is the first one that he has worked on for the whole lifecycle. Of the other projects he worked on, not one was for more than 5 months, and several of them were jobs that were being done at the same time and he was only a minor player in each one.
Added to that, the reason that his colleagues look to him, is that he makes changes without telling anyone or documenting the work - if someone has an issue, they check to see if it is caused by something that he has done. As for him being the one with the answers, it turns out that he has a direct line to some people that have a great deal of SAP experience, and whenever he hits a snag, he calls them - but then he presents their answer as his own.
Now to be fair, the guy has worked hard on our project - he has listed more days work than anyone else. He has dealt with complex requirements and produced some really good work, things that will eventually mean that we can get more out of our investment in SAP. It has taken a while but we are starting to see some of the benefits, and if we persist, I think that we will eventually have a system that we can be proud of.
The problem for me tho', is that it has taken a lot longer to get where we need to be, and that his over confidence has not helped us. A big issue is that he doesn't want to share his knowledge - he likes to do the work himself. This may be quicker in the short term, but it is clear that a key requirement for success with SAP is knowledge transfer, getting people to learn how to do things for themselves. It's also very frustrating when he makes decisons without sharing the reasons behind them - and particularly when subsequently they prove to be wrong, so that the work has to be re-done.
What really worries me is that now it has been agreed that this guy will be staying on to assist with carrying out a software upgrade instead of one of their basis guys being made available. I did ask him if he had done this work before, and he became quite incensed by the question, accusing me of not trusting him. Well it is quite simple - I can't trust him as he has been proven wrong several times with fairly serious consequences. The upgrade is a major step, and he has never even installed the software before, yet he seems to be utterly confident that he can do the upgrade work without a hitch.
Well we will see.
In fact, at one previous position, I was known as the "go-to guy" - if they had an issue, the first name that came up was mine. Where was I. what was I doing, could I be moved to take care of the problem. My direct manager loved to use football metaphors -he told me that whenever someone fumbled the ball, they looked to me to pick it up and run with it.
Having said that, I recognise that I don't always know the answer. Sometimes, it is necessary to fully analyse a problem, and look at alternative answers before choosing a course of action. It's often necessary to look to other people for advice and support - and sometimes even relatively junior members of staff can have good ideas. It's foolish to ignore these just because of the status of the person, but a lot of people will do just that. And I'm more than happy to accept that I've made a few bad decisions at times - but I always try to learn from these so that I can prevent them being made again.
The problem is that sometimes, confidence can cross the line into arrogance. I would suggest that a couple of our consultants have crossed that line - and one guy in particular stands out.
When we first started the project, some 3 years ago, we were given a series of resumes of the people that would be working on the project with us from the consultancy. These looked really good, with a group of people that had all had at least 6 projects and and an average of 8 years working with SAP.
Unfortunately, none of these people were ever "available" to actually work on our project, so we had a group of people that we knew little about. What became clear was that in most cases, they had limited experience - an average of 2 or 3 projects with at most a couple of years experience.
However, the one particular guy was uber confident - if you listened to him, he had almost 20 years experience of SAP and had worked on literally dozens of projects. He certainly seemed to be the one that the others looked to for advice whatever the problem.
As it happens, I met someone that knows this guy from a previous implementation. It turns out that he actually only has had coming up for 6 years experience, and our project is the first one that he has worked on for the whole lifecycle. Of the other projects he worked on, not one was for more than 5 months, and several of them were jobs that were being done at the same time and he was only a minor player in each one.
Added to that, the reason that his colleagues look to him, is that he makes changes without telling anyone or documenting the work - if someone has an issue, they check to see if it is caused by something that he has done. As for him being the one with the answers, it turns out that he has a direct line to some people that have a great deal of SAP experience, and whenever he hits a snag, he calls them - but then he presents their answer as his own.
Now to be fair, the guy has worked hard on our project - he has listed more days work than anyone else. He has dealt with complex requirements and produced some really good work, things that will eventually mean that we can get more out of our investment in SAP. It has taken a while but we are starting to see some of the benefits, and if we persist, I think that we will eventually have a system that we can be proud of.
The problem for me tho', is that it has taken a lot longer to get where we need to be, and that his over confidence has not helped us. A big issue is that he doesn't want to share his knowledge - he likes to do the work himself. This may be quicker in the short term, but it is clear that a key requirement for success with SAP is knowledge transfer, getting people to learn how to do things for themselves. It's also very frustrating when he makes decisons without sharing the reasons behind them - and particularly when subsequently they prove to be wrong, so that the work has to be re-done.
What really worries me is that now it has been agreed that this guy will be staying on to assist with carrying out a software upgrade instead of one of their basis guys being made available. I did ask him if he had done this work before, and he became quite incensed by the question, accusing me of not trusting him. Well it is quite simple - I can't trust him as he has been proven wrong several times with fairly serious consequences. The upgrade is a major step, and he has never even installed the software before, yet he seems to be utterly confident that he can do the upgrade work without a hitch.
Well we will see.
Subscribe to:
Posts (Atom)