Is lean anti-technology?
It shouldn’t be. But a lean organization also doesn’t adopt technology for technology’s sake.
There are often two camps in the “lean world.” There are those who really believe that lean is about no technology. Others believe that you can’t be lean without eKanban and ERP integration.
IndustryWeek covered the topic in High-Tech’s Role in Lean. The article is a bit one-sided, as represented in this quote:
“Pure lean principles need to be looked at in tandem with industry-leading best practices in supply chain, such as intelligent inventory management, response management and demand management, in order to create the ideal lean plant,” Viswanathan and Littlefield conclude. “Also, the approach of avoiding software is no longer realistic in today’s environment due to the simple fact that there are too many constraints, which cannot be handled manually with ad hoc tools.”
The survey conducted is awfully biased as well. It self-defines those who have adopted lots of technology as “best-in-class.”
A Real Lean View on Technology
A true lean thinking organization starts with the problem or the barrier. What problem am I trying to solve? Instead of evaluating the technology to see if it “looks good” it was start with the problem. If technology is the best, most reliable, and simplest way to overcome the problem, then a lean thinker would gladly adopt it. As long as it doesn’t prevent future improvements.
Here are some questions you should be asking yourself before adopting technology:
- What problem are we trying to solve? What barrier are we trying to overcome?
- Does this solution get us closer to our ideal state?
- Does this solution limit are flexibility? Are future improvements more difficult?
- Does this solution limit our visibility? Will we know if and why we have problems?
A lean-thinking organization doesn’t adopt technology. It solves problems. And it uses technology as solutions.
Good post. I am not part of the lean world if the the set named “lean world” exclusively consists of “no technology” and “ekanban / ERP”. I have been somewhere in the middle – more case by case.
My experience supports your postulate that most people do fall into one of those two camps. One of the guys that I blog with hates the use of any technology. Other people I have met missed the added syllable in autonomation and think that lean is about as much automation as your capital budget can handle. I agree with your position that the lean paradigm is technology neutral but I like the principle from The Way that says that it should be thoroughly tested and reliable and support people and processes. My mental powers are far too adequate to quantify the amount of errors and waste that I have seen by making some person do a bad process because that is the way some application was designed by a software designer far removed from the gemba. We sometimes bend people and process to ‘the will’ of the technology when it should obviously be the opposite.
Good post. I am not part of the lean world if the the set named “lean world” exclusively consists of “no technology” and “ekanban / ERP”. I have been somewhere in the middle – more case by case.
My experience supports your postulate that most people do fall into one of those two camps. One of the guys that I blog with hates the use of any technology. Other people I have met missed the added syllable in autonomation and think that lean is about as much automation as your capital budget can handle. I agree with your position that the lean paradigm is technology neutral but I like the principle from The Way that says that it should be thoroughly tested and reliable and support people and processes. My mental powers are far too adequate to quantify the amount of errors and waste that I have seen by making some person do a bad process because that is the way some application was designed by a software designer far removed from the gemba. We sometimes bend people and process to ‘the will’ of the technology when it should obviously be the opposite.
Good post. I am not part of the lean world if the the set named “lean world” exclusively consists of “no technology” and “ekanban / ERP”. I have been somewhere in the middle – more case by case.
My experience supports your postulate that most people do fall into one of those two camps. One of the guys that I blog with hates the use of any technology. Other people I have met missed the added syllable in autonomation and think that lean is about as much automation as your capital budget can handle. I agree with your position that the lean paradigm is technology neutral but I like the principle from The Way that says that it should be thoroughly tested and reliable and support people and processes. My mental powers are far too adequate to quantify the amount of errors and waste that I have seen by making some person do a bad process because that is the way some application was designed by a software designer far removed from the gemba. We sometimes bend people and process to ‘the will’ of the technology when it should obviously be the opposite.
sorry forgot to turn the strong tag off after the NO in autonomation on previous post. I apologize. It was not my intent to graffiti your blog.
sorry forgot to turn the strong tag off after the NO in autonomation on previous post. I apologize. It was not my intent to graffiti your blog.
sorry forgot to turn the strong tag off after the NO in autonomation on previous post. I apologize. It was not my intent to graffiti your blog.
Thanks Bruce.
I agree, a lean thinker pays as much attention to how, or the process, technology gets adopted as they pay to what technology gets adopted. Signing the purchase agreement is not a process for adoption.
Thanks Bruce.
I agree, a lean thinker pays as much attention to how, or the process, technology gets adopted as they pay to what technology gets adopted. Signing the purchase agreement is not a process for adoption.
Thanks Bruce.
I agree, a lean thinker pays as much attention to how, or the process, technology gets adopted as they pay to what technology gets adopted. Signing the purchase agreement is not a process for adoption.
Great post Jamie. Bruce also makes a very fundamental point that is core to successful use of technology in support of lean (or any initiative) – “making some person do a bad process because that is the way some application was designed by a software designer far removed from the gemba.” The software designer should not only be geographically close to the gemba, but also with a process understanding that is best achieved by working very closely with the people that will be impacted the technology, both users and benefactors.
Great post Jamie. Bruce also makes a very fundamental point that is core to successful use of technology in support of lean (or any initiative) – “making some person do a bad process because that is the way some application was designed by a software designer far removed from the gemba.” The software designer should not only be geographically close to the gemba, but also with a process understanding that is best achieved by working very closely with the people that will be impacted the technology, both users and benefactors.
Great post Jamie. Bruce also makes a very fundamental point that is core to successful use of technology in support of lean (or any initiative) – “making some person do a bad process because that is the way some application was designed by a software designer far removed from the gemba.” The software designer should not only be geographically close to the gemba, but also with a process understanding that is best achieved by working very closely with the people that will be impacted the technology, both users and benefactors.
Ah Bruce, tripped up by technology!
I’m suspicious of “intelligent” this or “optimized” that from the software world. I’m not anti-technology, but I believe strongly in the Toyota Way principle that you should only use well-tested technology that serves your people and your processes. Too many hospitals look for a silver bullet technology solution, maybe they’re worse than factories on this front, even.
Look at all the hype around Electronic Medical Records… you have the same promise and pitfalls as ERP in manufacturing, it’s a pretty similar sad tale oftentimes. Too many design and implementation decisions are made far away from the gemba, not involving the nurses or docs or other users… and we wonder why quality is poor and costs are high?
Ah Bruce, tripped up by technology!
I’m suspicious of “intelligent” this or “optimized” that from the software world. I’m not anti-technology, but I believe strongly in the Toyota Way principle that you should only use well-tested technology that serves your people and your processes. Too many hospitals look for a silver bullet technology solution, maybe they’re worse than factories on this front, even.
Look at all the hype around Electronic Medical Records… you have the same promise and pitfalls as ERP in manufacturing, it’s a pretty similar sad tale oftentimes. Too many design and implementation decisions are made far away from the gemba, not involving the nurses or docs or other users… and we wonder why quality is poor and costs are high?
Ah Bruce, tripped up by technology!
I’m suspicious of “intelligent” this or “optimized” that from the software world. I’m not anti-technology, but I believe strongly in the Toyota Way principle that you should only use well-tested technology that serves your people and your processes. Too many hospitals look for a silver bullet technology solution, maybe they’re worse than factories on this front, even.
Look at all the hype around Electronic Medical Records… you have the same promise and pitfalls as ERP in manufacturing, it’s a pretty similar sad tale oftentimes. Too many design and implementation decisions are made far away from the gemba, not involving the nurses or docs or other users… and we wonder why quality is poor and costs are high?
One of my personal rants–Lean is technology, and technology is “know-how,” if “tech” literally the root of how to do something, and “ology” is knowing or study. Using “technology” and “intelligent” to refer just to IT and electronic technology even leaves out automation in the popular press.
I’ve hear enough of the inside story of developing IT systems, even for advanced lean applications like those in the auto companies, to have a prejudice against them, even though there are some examples of information systems that are based on lean thinking. Highly paid “business analysts” and consultants sit in a room in an office building debating insignificant issues and burn money without ever setting foot in a plant. Meanwhile they perpetuate processes, like populating a whole new database for a model year change (taking the work of several people for several weeks) when it is now simply a set of engineering changes that take place in one point in time. It is simply another attribute of a product variation. This blindness is not only stupid, it shackles the company for the life of that system, which is usually about 20 years.
I continue to return to Jeff Liker’s story of the head of Motomachi who looked at the IT guy’s beautiful systems plan and swept it off the table telling him to come back after he’d produced something that would help them build cars. Toyota does use a lot of automation and IT, but it also tears it out where it is not doing any good.
Support the making of the product or service, work in the gemba, follow the process, make the system flexible and easy to change, prototype and release in a spiral fashion.
One of my personal rants–Lean is technology, and technology is “know-how,” if “tech” literally the root of how to do something, and “ology” is knowing or study. Using “technology” and “intelligent” to refer just to IT and electronic technology even leaves out automation in the popular press.
I’ve hear enough of the inside story of developing IT systems, even for advanced lean applications like those in the auto companies, to have a prejudice against them, even though there are some examples of information systems that are based on lean thinking. Highly paid “business analysts” and consultants sit in a room in an office building debating insignificant issues and burn money without ever setting foot in a plant. Meanwhile they perpetuate processes, like populating a whole new database for a model year change (taking the work of several people for several weeks) when it is now simply a set of engineering changes that take place in one point in time. It is simply another attribute of a product variation. This blindness is not only stupid, it shackles the company for the life of that system, which is usually about 20 years.
I continue to return to Jeff Liker’s story of the head of Motomachi who looked at the IT guy’s beautiful systems plan and swept it off the table telling him to come back after he’d produced something that would help them build cars. Toyota does use a lot of automation and IT, but it also tears it out where it is not doing any good.
Support the making of the product or service, work in the gemba, follow the process, make the system flexible and easy to change, prototype and release in a spiral fashion.
One of my personal rants–Lean is technology, and technology is “know-how,” if “tech” literally the root of how to do something, and “ology” is knowing or study. Using “technology” and “intelligent” to refer just to IT and electronic technology even leaves out automation in the popular press.
I’ve hear enough of the inside story of developing IT systems, even for advanced lean applications like those in the auto companies, to have a prejudice against them, even though there are some examples of information systems that are based on lean thinking. Highly paid “business analysts” and consultants sit in a room in an office building debating insignificant issues and burn money without ever setting foot in a plant. Meanwhile they perpetuate processes, like populating a whole new database for a model year change (taking the work of several people for several weeks) when it is now simply a set of engineering changes that take place in one point in time. It is simply another attribute of a product variation. This blindness is not only stupid, it shackles the company for the life of that system, which is usually about 20 years.
I continue to return to Jeff Liker’s story of the head of Motomachi who looked at the IT guy’s beautiful systems plan and swept it off the table telling him to come back after he’d produced something that would help them build cars. Toyota does use a lot of automation and IT, but it also tears it out where it is not doing any good.
Support the making of the product or service, work in the gemba, follow the process, make the system flexible and easy to change, prototype and release in a spiral fashion.
As an IT guy building lean software I’ll dare to offer a couple of comments.
It’s always instructive to look at who funds the research report since the analyst firm’s work will always reflect the desired outcome of their customer at least to some degree. The survey results then aren’t a surprise.
The comments about software developers not getting out to understand the process in detail are well founded. And it will show up in ease of use and functionality of the software. I can’t tell you the amount I’ve learned from each customer that has resulted in new capabilities that expand on a more simplistic base. The challenge with a generic product is to maintain the proper balance between over-engineering and complexity vs. handling every unique situation.
I’d offer another consideration for the use of technology. Use the simplest technology possible. If you can do it on a whiteboard, that’s great. If you can do it in Excel, fine. But recognize that there are situations where the amount of data, the dynamics of rapid change, and the complexity of the situation will require a more sophisticated solution. Then it’s time to find the right technology that solves the problem. At the end of the day, technology is not an end in itself, only a means to move us closer to the ideal state.
And last, while lean should be technology agnostic, in practice it certainly isn’t. The anti-technology bias is very strong. Unfortunately the operative word is “bias” which connotes a unwillingness to consider other alternatives.
As an IT guy building lean software I’ll dare to offer a couple of comments.
It’s always instructive to look at who funds the research report since the analyst firm’s work will always reflect the desired outcome of their customer at least to some degree. The survey results then aren’t a surprise.
The comments about software developers not getting out to understand the process in detail are well founded. And it will show up in ease of use and functionality of the software. I can’t tell you the amount I’ve learned from each customer that has resulted in new capabilities that expand on a more simplistic base. The challenge with a generic product is to maintain the proper balance between over-engineering and complexity vs. handling every unique situation.
I’d offer another consideration for the use of technology. Use the simplest technology possible. If you can do it on a whiteboard, that’s great. If you can do it in Excel, fine. But recognize that there are situations where the amount of data, the dynamics of rapid change, and the complexity of the situation will require a more sophisticated solution. Then it’s time to find the right technology that solves the problem. At the end of the day, technology is not an end in itself, only a means to move us closer to the ideal state.
And last, while lean should be technology agnostic, in practice it certainly isn’t. The anti-technology bias is very strong. Unfortunately the operative word is “bias” which connotes a unwillingness to consider other alternatives.
As an IT guy building lean software I’ll dare to offer a couple of comments.
It’s always instructive to look at who funds the research report since the analyst firm’s work will always reflect the desired outcome of their customer at least to some degree. The survey results then aren’t a surprise.
The comments about software developers not getting out to understand the process in detail are well founded. And it will show up in ease of use and functionality of the software. I can’t tell you the amount I’ve learned from each customer that has resulted in new capabilities that expand on a more simplistic base. The challenge with a generic product is to maintain the proper balance between over-engineering and complexity vs. handling every unique situation.
I’d offer another consideration for the use of technology. Use the simplest technology possible. If you can do it on a whiteboard, that’s great. If you can do it in Excel, fine. But recognize that there are situations where the amount of data, the dynamics of rapid change, and the complexity of the situation will require a more sophisticated solution. Then it’s time to find the right technology that solves the problem. At the end of the day, technology is not an end in itself, only a means to move us closer to the ideal state.
And last, while lean should be technology agnostic, in practice it certainly isn’t. The anti-technology bias is very strong. Unfortunately the operative word is “bias” which connotes a unwillingness to consider other alternatives.
Jamie,
Great question! It has prompted some great comments. I hope my comment is worthy of the others.
After having worked as general manager in a manufacturing environment during it’s lean journey and as general manager for a downstream production automation software company, I have to say that lean and technology depend on each other for best case success.
In my experience, many leaders of companies will mistakenly assume that, if software technology is installed, the software will seek out and discover the most efficient processes, thereby absolving the organization of the responsibility and time to develop solutions themselves. This is a thought process of laziness, the results of which are littered with software failures.
Lean is best served by line and staff personnel discovering and developing the most efficient processes themselves without the assistance of technology. The organization discovers the solutions as a team, own the solutions, and are more likely to gain and sustain a belief system in lean.
Where technology assists lean is in the continuity of ongoing implementation and discoveries of new idea suggestions for lean improvement. Software, in particular, downstream automation software, has the capability to make suggestions in real time, based on lean business rules. But until the business rules of lean are established, such software technology is incapable to make best suggestions.
There is a low risk tolerance for software techology in the manufacturing sector, which also creates the divisive effect of which your question speaks.
Jamie,
Great question! It has prompted some great comments. I hope my comment is worthy of the others.
After having worked as general manager in a manufacturing environment during it’s lean journey and as general manager for a downstream production automation software company, I have to say that lean and technology depend on each other for best case success.
In my experience, many leaders of companies will mistakenly assume that, if software technology is installed, the software will seek out and discover the most efficient processes, thereby absolving the organization of the responsibility and time to develop solutions themselves. This is a thought process of laziness, the results of which are littered with software failures.
Lean is best served by line and staff personnel discovering and developing the most efficient processes themselves without the assistance of technology. The organization discovers the solutions as a team, own the solutions, and are more likely to gain and sustain a belief system in lean.
Where technology assists lean is in the continuity of ongoing implementation and discoveries of new idea suggestions for lean improvement. Software, in particular, downstream automation software, has the capability to make suggestions in real time, based on lean business rules. But until the business rules of lean are established, such software technology is incapable to make best suggestions.
There is a low risk tolerance for software techology in the manufacturing sector, which also creates the divisive effect of which your question speaks.
Jamie,
Great question! It has prompted some great comments. I hope my comment is worthy of the others.
After having worked as general manager in a manufacturing environment during it’s lean journey and as general manager for a downstream production automation software company, I have to say that lean and technology depend on each other for best case success.
In my experience, many leaders of companies will mistakenly assume that, if software technology is installed, the software will seek out and discover the most efficient processes, thereby absolving the organization of the responsibility and time to develop solutions themselves. This is a thought process of laziness, the results of which are littered with software failures.
Lean is best served by line and staff personnel discovering and developing the most efficient processes themselves without the assistance of technology. The organization discovers the solutions as a team, own the solutions, and are more likely to gain and sustain a belief system in lean.
Where technology assists lean is in the continuity of ongoing implementation and discoveries of new idea suggestions for lean improvement. Software, in particular, downstream automation software, has the capability to make suggestions in real time, based on lean business rules. But until the business rules of lean are established, such software technology is incapable to make best suggestions.
There is a low risk tolerance for software techology in the manufacturing sector, which also creates the divisive effect of which your question speaks.
Jamie, this is an excellent post and has generated some thought-provoking comments. Reminds me of my early days in consulting with KPMG. We often deliberated how to best automate a client’s financial reporting processes and still keep things simple enough for everyone to see and understand, i.e., information which actually provided value as opposed to that which only delivered fluff.
But let me comment with this slightly different twist on the survey material which is the foundation for this article to begin with. Both AMR Research and the Aberdeen Group provide sponsored research. The articles or reports written as a result of this research, and of course the research itself, are paid for by companies which sell the product or service being researched. Those companies can then cite this research as the authority which supports the value of that product or service to prospective clients. Gettin’ the picture?
I recently received a complimentary research report from Aberdeen on “Integrated Talent Management” (Abdereen’s “suggested value $399, but no charge to me, and for a limited time only). This report was prepared “in cooperation with” seven vendors of talent management software; all seven vendor names appeared in the email promotion as well as in the article itself. When was the last time we saw a research report sponsored by Pfizer on the efficacy of Viagra ™ that said the stuff doesn’t work?
So, perhaps that’s why the article, as you note, appears to be “a bit one-sided…”
And that’s the way I see it.
Adam Zak
Jamie, this is an excellent post and has generated some thought-provoking comments. Reminds me of my early days in consulting with KPMG. We often deliberated how to best automate a client’s financial reporting processes and still keep things simple enough for everyone to see and understand, i.e., information which actually provided value as opposed to that which only delivered fluff.
But let me comment with this slightly different twist on the survey material which is the foundation for this article to begin with. Both AMR Research and the Aberdeen Group provide sponsored research. The articles or reports written as a result of this research, and of course the research itself, are paid for by companies which sell the product or service being researched. Those companies can then cite this research as the authority which supports the value of that product or service to prospective clients. Gettin’ the picture?
I recently received a complimentary research report from Aberdeen on “Integrated Talent Management” (Abdereen’s “suggested value $399, but no charge to me, and for a limited time only). This report was prepared “in cooperation with” seven vendors of talent management software; all seven vendor names appeared in the email promotion as well as in the article itself. When was the last time we saw a research report sponsored by Pfizer on the efficacy of Viagra ™ that said the stuff doesn’t work?
So, perhaps that’s why the article, as you note, appears to be “a bit one-sided…”
And that’s the way I see it.
Adam Zak
Jamie, this is an excellent post and has generated some thought-provoking comments. Reminds me of my early days in consulting with KPMG. We often deliberated how to best automate a client’s financial reporting processes and still keep things simple enough for everyone to see and understand, i.e., information which actually provided value as opposed to that which only delivered fluff.
But let me comment with this slightly different twist on the survey material which is the foundation for this article to begin with. Both AMR Research and the Aberdeen Group provide sponsored research. The articles or reports written as a result of this research, and of course the research itself, are paid for by companies which sell the product or service being researched. Those companies can then cite this research as the authority which supports the value of that product or service to prospective clients. Gettin’ the picture?
I recently received a complimentary research report from Aberdeen on “Integrated Talent Management” (Abdereen’s “suggested value $399, but no charge to me, and for a limited time only). This report was prepared “in cooperation with” seven vendors of talent management software; all seven vendor names appeared in the email promotion as well as in the article itself. When was the last time we saw a research report sponsored by Pfizer on the efficacy of Viagra ™ that said the stuff doesn’t work?
So, perhaps that’s why the article, as you note, appears to be “a bit one-sided…”
And that’s the way I see it.
Adam Zak
I think it would be correct to say that lean is anti “technology push”. Whether it be in product design “we can add these cool features that increase cost and customers may not even want!” or production equipment “look what my six axis machining center can do, now in even bigger batches!” to software “we can put those visual controls on a 50 inch flat panel display running enterprise software-enabled real-time dashboards” the idea with lean is to find the root cause of the problem and apply the simplest, lowest cost and most appropriate countermeasure. The “because we can” technology push is rarely that.
I think it would be correct to say that lean is anti “technology push”. Whether it be in product design “we can add these cool features that increase cost and customers may not even want!” or production equipment “look what my six axis machining center can do, now in even bigger batches!” to software “we can put those visual controls on a 50 inch flat panel display running enterprise software-enabled real-time dashboards” the idea with lean is to find the root cause of the problem and apply the simplest, lowest cost and most appropriate countermeasure. The “because we can” technology push is rarely that.
I think it would be correct to say that lean is anti “technology push”. Whether it be in product design “we can add these cool features that increase cost and customers may not even want!” or production equipment “look what my six axis machining center can do, now in even bigger batches!” to software “we can put those visual controls on a 50 inch flat panel display running enterprise software-enabled real-time dashboards” the idea with lean is to find the root cause of the problem and apply the simplest, lowest cost and most appropriate countermeasure. The “because we can” technology push is rarely that.
Great comments. I want to respond to each one, but I’ll try my best instead just to sum up the key points and common threads:
1. lean and technology can work together
2. know the problem first, use technology only as a solution
3. keep it simple
4. prove the technology before unleashing on people
5. go and see, either the use or the problem, before trying to fix it
Thanks.
Great comments. I want to respond to each one, but I’ll try my best instead just to sum up the key points and common threads:
1. lean and technology can work together
2. know the problem first, use technology only as a solution
3. keep it simple
4. prove the technology before unleashing on people
5. go and see, either the use or the problem, before trying to fix it
Thanks.
Great comments. I want to respond to each one, but I’ll try my best instead just to sum up the key points and common threads:
1. lean and technology can work together
2. know the problem first, use technology only as a solution
3. keep it simple
4. prove the technology before unleashing on people
5. go and see, either the use or the problem, before trying to fix it
Thanks.
Great post and comments! I agree with the key points by Jamie and I can tell you that I worked at a company that was addicted to technology. They had miles of conveyor and tried to automate everything possible for a very simple computer assembly process. We gutted it and revamped it but we really had to emphasis doing design work with out technology first just to break the old habits and thought patterns.
You don’t give a diabetic more sugar on his/her diet so to normalize you have to give proper food that keeps insulin under control. The same is true for Lean. If the company is addicted to technology you need to detox before going forward. I would force at least 7 alternative designs (ala 3P method) and have at least 3-4 designs that are no automation no technology in terms of IT support.
It worked out great and as we detoxed from our automation addiction we introduced some new technologies like devices that would help move the computers. But the technologies were reliable!
Ankit
http://TheLeanWayConsulting.blogspot.com
Great post and comments! I agree with the key points by Jamie and I can tell you that I worked at a company that was addicted to technology. They had miles of conveyor and tried to automate everything possible for a very simple computer assembly process. We gutted it and revamped it but we really had to emphasis doing design work with out technology first just to break the old habits and thought patterns.
You don’t give a diabetic more sugar on his/her diet so to normalize you have to give proper food that keeps insulin under control. The same is true for Lean. If the company is addicted to technology you need to detox before going forward. I would force at least 7 alternative designs (ala 3P method) and have at least 3-4 designs that are no automation no technology in terms of IT support.
It worked out great and as we detoxed from our automation addiction we introduced some new technologies like devices that would help move the computers. But the technologies were reliable!
Ankit
http://TheLeanWayConsulting.blogspot.com
Great post and comments! I agree with the key points by Jamie and I can tell you that I worked at a company that was addicted to technology. They had miles of conveyor and tried to automate everything possible for a very simple computer assembly process. We gutted it and revamped it but we really had to emphasis doing design work with out technology first just to break the old habits and thought patterns.
You don’t give a diabetic more sugar on his/her diet so to normalize you have to give proper food that keeps insulin under control. The same is true for Lean. If the company is addicted to technology you need to detox before going forward. I would force at least 7 alternative designs (ala 3P method) and have at least 3-4 designs that are no automation no technology in terms of IT support.
It worked out great and as we detoxed from our automation addiction we introduced some new technologies like devices that would help move the computers. But the technologies were reliable!
Ankit
http://TheLeanWayConsulting.blogspot.com
Keep posting stuff like this i really like it
Keep posting stuff like this i really like it
Keep posting stuff like this i really like it