Here is the worst thing I've ever read: big consulting companies are automating processes with bots. This was posted in the Australian Financial Review and written by Edmund Tadros.
So let me get this straight. These huge consulting companies are going to come into a company, recommend that they spend millions, or tens of millions of dollars on complicated software packages and then spend millions more to write bots to use them. Brilliant. Brilliant that is if you are a consulting company. You'll get the original markup on the software, the bill rate ($200 or more per hour) to install and configure it, $200 per hour to secure it (kind of), $200 per hour to copy and paste data in and out of it (forever) and then a couple of hunsky per hour to write these bots. That is a little bit like buying an old Ford Tractor, a 1976 AMC Pacer and a filing cabinet and hiring a bunch of engineers to cobble them together into a machine that you can use to haul hay.
If you are going to spend tens of millions on applications (some hospitals spend hundreds of millions) why not write something that does everything you need to do from scratch and be done with it? This eliminates the need for integration, it streamlines (and even makes possible) security, and will be far FAR less expensive. Look, you are writing custom software anyway with these bots, so why not get rid of the complication, look at the inputs and the desired outputs and go from point A to point B in a straight line at a known, measured pace?
I've said for years that I could run Bank of America with 20% of the people they use. That would eliminate 80% of the cost and either they could make 80% more profit or drop prices by 80% and put everyone else out of business. Both those outcomes are desirable.
Here is what your consulting company needs to do: Build one application that does everything your company does, does it automatically and spits out a report at the end of the month detailing how much money you made. We've done that with several businesses before. Not one, not two. Several. Sure, there are times you don't want to reinvent the wheel. If you have a machine that keeps its own database, internally, use that data. Use it right where it sits, but use it as if it were native. Don't import it.
Quit hiring the big consulting companies. Their job is to bill hours and clean out your pockets. If you need help, and you do, call someone who sees the big picture who will take your inputs and truly automate your processes so you get that report at the end of the month telling you how much you made. Free your employees to think and innovate and become profit centers not cost centers. If you see your software as a cost of doing business or a hurdle to be jumped or a necessary evil, you are looking at it the wrong way. We will help you reduce costs, make more sales and make things faster, better and cheaper. What we won't do is sell you unsecurable, prepackaged garbage that you don't need then add layers of complication that will cost outrageous amounts and end up breaking.
Wednesday, September 28, 2016
Tuesday, September 27, 2016
Making EMRs Fast, Easy and Intuitive to Use: Removing the Burden of Structured Data
I was cruising around last week and came across "The Burden of Structured Data: What can Healthcare Learn From The Web Experience" from Andy Oram who's writing I have quoted here before. In the second part of the article (the second part is the reason I didn't respond to it last week) he states "ICD should be replaced with something that embodies semantic meaning" and then goes on to say "A big problem in electronic health records is their insistence that certain things be filled out for every patient." resulting in a "Cartesian explosion" and "bloated records."
As we have found before, Andy makes some good observations, but like the healthcare industry in general, he has no clue how to solve the problem or that the problem has already been solved. It seems to me that Google, Bing, and all the other major search engines pretty much licked this problem a long time ago. They give you a two stage search where what you type in generates suggestions AS YOU TYPE with popular searches. That isn't quite the entire solution for healthcare, but that is a great place to start.
The entire solution is to use a purpose built database like SNOMED CT that is designed from the outset for documenting patient encounters and combining it with Bing style searches. That is precisely what we have done here at Sentia Systems, for our sister company Sentia Health. Our solution takes it a bit farther even. We took all the concepts in the SNOMED and made a word table with the number of unique occurrences of every word in every concept. When the user picks a word out of the autocomplete list, we insert that word and a space making compound word searches possible. For example, "abd" would give you "abdominal" and "pa" would give you "pain" and f course we are bright enough to return the matching word with the highest number of occurrences first. Then we do the bing/google thing and search the appropriate concept type for places where "abdominal" is near or next to "pain." This isn't just a wildcard search either. For you techies out there, it is a full text index, meaning that we search for words that SOUND LIKE "abdominal" and "pain" in case the user didn't pick from the list, and in reverse order and NEAR each other, not just next to, or in the same description.
Here are a few pictures to illustrate what we mean:
First we navigate to the appropriate record, open the search window and type "lo":
Then we pick (or continue typing) lower and continue with "ab":
Then we continue typing (or pick) "pa":
Finally, we click the Populate button to actually do the search:
There are quite a few things to notice here:
So yes, Andy (or is it Mr. Oram?), we have conquered the structured data challenge. We document our cases in regular SOAP Notes that are in English (SNOMED also supports many other languages and will translate them automatically) with modifiers (like "left" or "severe") indented and prefaced with a dash.
This is what software is supposed to do: solve problems. We believe that we can enter in a note as fast as we could have typed it in and with far fewer typographical errors. Even better, we now can search for patients with a diagnosis, or with certain symptoms because those things are captured in a structured way.
So tell your Cerners and your Epics and every other vendor of electronic health records out there that they are just doing it wrong. When you factor in the fact that an Epic or a Cerner installation will cost hundreds of millions of dollars to implement, the response time is abysmal, the patient encounter still has to be coded to be paid by the insurance company, and our sister company Sentia Health will do all this, and do it better than the competition can even imagine, and do it for $10/month I think the choice is clear.
So no, Andy, there is no burden, you just need a few good programmers to show you how to do it.
As we have found before, Andy makes some good observations, but like the healthcare industry in general, he has no clue how to solve the problem or that the problem has already been solved. It seems to me that Google, Bing, and all the other major search engines pretty much licked this problem a long time ago. They give you a two stage search where what you type in generates suggestions AS YOU TYPE with popular searches. That isn't quite the entire solution for healthcare, but that is a great place to start.
The entire solution is to use a purpose built database like SNOMED CT that is designed from the outset for documenting patient encounters and combining it with Bing style searches. That is precisely what we have done here at Sentia Systems, for our sister company Sentia Health. Our solution takes it a bit farther even. We took all the concepts in the SNOMED and made a word table with the number of unique occurrences of every word in every concept. When the user picks a word out of the autocomplete list, we insert that word and a space making compound word searches possible. For example, "abd" would give you "abdominal" and "pa" would give you "pain" and f course we are bright enough to return the matching word with the highest number of occurrences first. Then we do the bing/google thing and search the appropriate concept type for places where "abdominal" is near or next to "pain." This isn't just a wildcard search either. For you techies out there, it is a full text index, meaning that we search for words that SOUND LIKE "abdominal" and "pain" in case the user didn't pick from the list, and in reverse order and NEAR each other, not just next to, or in the same description.
Here are a few pictures to illustrate what we mean:
First we navigate to the appropriate record, open the search window and type "lo":
Then we pick (or continue typing) lower and continue with "ab":
Then we continue typing (or pick) "pa":
Finally, we click the Populate button to actually do the search:
There are quite a few things to notice here:
- The autocomplete doesn't give you popular searches, like Google does. It simply corrects your spelling. This allows you to only get 25 results with two letters instead of scrolling through thousands of results that would take a long time up load in any case.
- You can type your entire entry with out picking anything. If you don't want to use the mouse or the scroll buttons, don't.
- The thing you actually wanted to see is at the top, number one position. Other things that might be similar are ranked below.
- If you choose to type, without picking anything in the autocomplete, the spell checking still kicks in. If you search 'hedayk' you still get a list of things with headache in the title, just like Bing.
So yes, Andy (or is it Mr. Oram?), we have conquered the structured data challenge. We document our cases in regular SOAP Notes that are in English (SNOMED also supports many other languages and will translate them automatically) with modifiers (like "left" or "severe") indented and prefaced with a dash.
This is what software is supposed to do: solve problems. We believe that we can enter in a note as fast as we could have typed it in and with far fewer typographical errors. Even better, we now can search for patients with a diagnosis, or with certain symptoms because those things are captured in a structured way.
So tell your Cerners and your Epics and every other vendor of electronic health records out there that they are just doing it wrong. When you factor in the fact that an Epic or a Cerner installation will cost hundreds of millions of dollars to implement, the response time is abysmal, the patient encounter still has to be coded to be paid by the insurance company, and our sister company Sentia Health will do all this, and do it better than the competition can even imagine, and do it for $10/month I think the choice is clear.
So no, Andy, there is no burden, you just need a few good programmers to show you how to do it.
Thursday, September 22, 2016
Beware of Buzzwords. Software Companies Are Selling You a Bill Of Goods
I was reading along yesterday when I ran across this from my buddy Anne Zieger over at EMR and HIPAA crowing about how Machine Learning might tame healthcare's Big Data. First, there is no such thing as Big Data. Depending on whom you talk to, the term big data was either coined by Dr. Francis Diebold at UPenn in a paper called A Personal Perspective on the Origin(s) and Development of \Big Data": The Phenomenon, the Term, and the Discipline or Roger Magoulas from Ultimately, big data is more about attitude than tools; data-driven organizations look at big data as a solution, not a problem. Either way, Big Data is a sales tool to get you to buy that worthless piece of nothing called Hadoop. Beware of Trojans bearing gifts and beware of people trying to sell you things. Hadoop and Map Reduce are combined to give a programmer the ability to sift through huge amounts of unstructured data. The problem with that is that they use Java to loop through this massive data store to look for things. If you've been following along with our blog, you already know why Java is particularly unsuited for this kind of work. Plus, we already have a tool for that and we've had it since 1979. Its called a database. No, databases can't handle unstructured data, but there is no such thing as unstructured data, there is only data that hasn't been structured yet. At Sentia, our solution is to structure the data, shove it into a database and run queries against it. That requires no new technology and the first query will take about as long as doing it the dumb Hadoop way. The second Hadoop query will take just as long as the first, because it works exactly the same way as the first, but the second database query will take thousands of times less, because the data is already structured. If your database server can't handle the volume of data that your Hadoop servers can, format the boxes that Hadoop is installed on and add them to your database cluster. That should solve the problem.
Second (did you forget there was a first already?) just like Big Data, there is no such thing as Machine Learning, at least not yet. Margaret Rouse posted this definition on TechTarget, where she states that machine learning is used by Facebook "... to personalize each member's feed. If a member frequently stops scrolling in order to read or "like" a particular friend's posts, the News Feed will start to show more of that friend's activity earlier in the feed."
We here at Sentia call that a query (yes, on a database) and have been doing it for decades. Here's an example of how we do it. In the Electronic Medical Records (EMR) application we wrote for our sister company Sentia Health, we query the database to find the top twenty diagnoses by doctor in a rolling six week average and rank them by number of occurrences. This allows us to show the doctor a list of the most common things he or she is diagnosing that changes over time. for example, in the fall and winter influenza (the flu) rises to the top of the list and when the doctor selects it, he or she can duplicate the first instance of that diagnosis and copy it over to the new patient, literally completing the patient documentation with one click. We wrote that query in 2002, before there was "Big Data," Hadoop or "Machine Learning." Heck, that was before there even was a Facebook and long before it was open to everyone and FAR before they started using "Machine Learning" to update your newsfeed.
Why do we mention all this to you? We told you above: Beware of Trojans bearing gifts. The people who came up with all this are trying to sell you something. The reporters, in this case bloggers, don't have the faintest idea what they are talking about. Their job is to publish or perish, not to tell it to you straight. While Walter Cronkite didn't have to know what he was talking about to report the news, he just told you what happened and he tried not to put a spin on it. That isn't the case today. The sales people, and everyone hates a sales person, don't care what you think or what the product is as long as they get your cash. They are paid to come up with new verbiage to part a fool from his money. If you are falling for this, yes, you are a fool. If you don't have the tools necessary to winnow the wheat from the chaff in your software purchases, you are an idiot and you deserve what you get. that's fine as long as you are happy with it, but this affects everyone. It is most of the reason that healthcare is claiming 20% of the Gross Domestic Product in the United States. Idiot administrators are buying buzzwords from dishonest salespeople.
Here's another example: Athena Health claims they are a cloud based EMR. Athena is practice management and uses VPN to log in to a desktop remotely. Yes, you log into a windows machine with an installed, windows based application on it. That means every one of their clients has its own installation of their product. Talk about an expensive administration nightmare. That doesn't even count setting up all those machines with the application installed on them. "Cloud" is their buzzword. They want you to think their product is SaaS (Software as a Service) like our sister company Sentia Health provides, but the can't because they don't know how to build applications that run in a browser.
We've talked about buzzwords before. Buzzwords are designed to obfuscate facts and to put lipstick on the pig that a sales person is trying to foist off on you. Yes, YOU, dear reader. If you go to a doctor (or any other business) that buys into this, and all of you do, you end up paying for that polished porcine piece of prevarication out of your own personal pocket.
If you want real software, built without using mind numbing buzzwords, you know who to call. Don't make out with the red lipped porker, or buy a pig in a poke.
Second (did you forget there was a first already?) just like Big Data, there is no such thing as Machine Learning, at least not yet. Margaret Rouse posted this definition on TechTarget, where she states that machine learning is used by Facebook "... to personalize each member's feed. If a member frequently stops scrolling in order to read or "like" a particular friend's posts, the News Feed will start to show more of that friend's activity earlier in the feed."
We here at Sentia call that a query (yes, on a database) and have been doing it for decades. Here's an example of how we do it. In the Electronic Medical Records (EMR) application we wrote for our sister company Sentia Health, we query the database to find the top twenty diagnoses by doctor in a rolling six week average and rank them by number of occurrences. This allows us to show the doctor a list of the most common things he or she is diagnosing that changes over time. for example, in the fall and winter influenza (the flu) rises to the top of the list and when the doctor selects it, he or she can duplicate the first instance of that diagnosis and copy it over to the new patient, literally completing the patient documentation with one click. We wrote that query in 2002, before there was "Big Data," Hadoop or "Machine Learning." Heck, that was before there even was a Facebook and long before it was open to everyone and FAR before they started using "Machine Learning" to update your newsfeed.
Why do we mention all this to you? We told you above: Beware of Trojans bearing gifts. The people who came up with all this are trying to sell you something. The reporters, in this case bloggers, don't have the faintest idea what they are talking about. Their job is to publish or perish, not to tell it to you straight. While Walter Cronkite didn't have to know what he was talking about to report the news, he just told you what happened and he tried not to put a spin on it. That isn't the case today. The sales people, and everyone hates a sales person, don't care what you think or what the product is as long as they get your cash. They are paid to come up with new verbiage to part a fool from his money. If you are falling for this, yes, you are a fool. If you don't have the tools necessary to winnow the wheat from the chaff in your software purchases, you are an idiot and you deserve what you get. that's fine as long as you are happy with it, but this affects everyone. It is most of the reason that healthcare is claiming 20% of the Gross Domestic Product in the United States. Idiot administrators are buying buzzwords from dishonest salespeople.
Here's another example: Athena Health claims they are a cloud based EMR. Athena is practice management and uses VPN to log in to a desktop remotely. Yes, you log into a windows machine with an installed, windows based application on it. That means every one of their clients has its own installation of their product. Talk about an expensive administration nightmare. That doesn't even count setting up all those machines with the application installed on them. "Cloud" is their buzzword. They want you to think their product is SaaS (Software as a Service) like our sister company Sentia Health provides, but the can't because they don't know how to build applications that run in a browser.
We've talked about buzzwords before. Buzzwords are designed to obfuscate facts and to put lipstick on the pig that a sales person is trying to foist off on you. Yes, YOU, dear reader. If you go to a doctor (or any other business) that buys into this, and all of you do, you end up paying for that polished porcine piece of prevarication out of your own personal pocket.
If you want real software, built without using mind numbing buzzwords, you know who to call. Don't make out with the red lipped porker, or buy a pig in a poke.
Thursday, September 15, 2016
"Thinking outside the box," buzzwords and other dumb things that business people say and do
Management consultants and business guys in general are infamous for their meaningless clichés like "drink the Kool-Ade," "open the kimono" or "paradigm shift." Unless you studied Latin or Greek (I did) don't crow to me about paradigms. The worst of these is "thinking outside the box." The business people I have run across don't have the training or experience to truly even know where the walls of "the box" are, much less what is inside or not. I'm not really sure what an MBA prepares a person to do, but I can assure you it isn't innovative thinking.
For example, Sentia had a contract with Jack Henry & Associates in Charlotte to help them add on some regulatory functionality to their Cruise application for Credit Unions. The regulation was called "Tila/Respa." I don't recall what that meant but it was a disclosure of loan terms to the borrower. the regulation was huge, about 50 entities and and average of 20 attributes per entity, or a little over a thousand database fields. My guy got there on September 1 last year and the functionality had to be implemented by October 1. Designing and building a database, designing and building a middle tier and designing and building a user interface using two guys for a thousand plus fields is getting close to impossible. My guy wrote a tool that took the specification, scraped out the names and datatypes of the attributes, assigned them to entities and generated a database. The other guy, meanwhile, was working on a tool to generate Windows forms (yes it was a Windows application, ewww) from the same specification. My guy then pointed Sentia's Object Relational Mapper (ORM) at the new database and generated the middle tier. After some trial and error with naming conventions and such, the generated front end was mated to the generated middle tier and while ugly, worked fine. This whole process took a week. Of course then then the specification changed (six more times) but because we chose to generate the application in toto, all we had to do was regenerate the application and make it pretty.
Why do I tell you this story? As problem solvers, those two guys really "thought outside the box" and delivered not what the client asked for, but what they needed and compensated for the changes they knew were coming. Instead of doing as they were told and "coding tila/respa" (whatever that means) they looked ahead to changed they knew would come (they always do) and instead of slaving away, they designed a flexible solution that would solve the real problem. It was still a lot of hard work, and harder work than "coding tila/respa" (again, whatever that means) but less of it, and flexible enough to compensate for the shifting sands of a requirements document left until the last possible second. So these same two guys knowing that Cruise itself was a complete train wreck with possibly a dozen ways to access its own database, procedural code that has been around since the VB4 days, and generally didn't work and couldn't be fixed, suggested that they use the same methods to cut out all the old middle tier code and replace it with the new code generated from the database schema.
What was the response? "That can't be done."
Well, yes it can and my guy just did it.
In fact, our sister company Sentia Health, just went through a complete rewrite of its EMR's entire user interface a few months ago. That is fairly comparable to what my guy suggested to Jack Henry. In another month or so, we are going regenerate the middle tier with an upgraded version from the new ORM that we have developed. that is PRECISELY what we suggested to Jack Henry and they said couldn't be done.
I still haven't given you the reason I made you read the Jack Henry Story. Here it is: Business doesn't want "outside the box" thinking. Further, they don't recognize it when they see it, or even when it is shoved down their throats and proven to work. There it is. THAT is the reason.
So yeah, we still haven't addressed buzzwords. The business guys don't get those either. XML, Web Services, XAML, Big Data, WPF, WCF, SOAP, REST, NoSQL, Hadoop, don't make sense in most applications and some don't make any sense at all. "The smart guys got a PhD for a dissertation on Big Data so I need some Big Data in my solution!" Well, no, you don't and there is no such thing as big data. Microsoft has a Big Data solution and it has been around for decades: SQL Server. Don't run procedural code against your unstructured data, structure it and run set based code using a database engine.
So once again, it is conclusion time. Until we quit letting the MBAs run anything, including their mouths, we are never going to get anywhere useful. Regular readers will recognize the Bob Cratchit theory: Businesses are doing nothing differently now than they did in 1843 at Scrooge and Marley's counting house, they just have the spreadsheets on a computer today.
The conclusion of the conclusion is to let the MBAs worry about funding and shares and corporate structure. Let the truly smart people decide HOW things are going to be done. THIS is what we have and THAT is what we want and we software guys will show you the best way to get from THIS to THAT. At Sentia we have automated entire businesses. Not just one, not two, but many. We took an existing business and automated it to the point that there is nothing to do but click the "Send bills" button at the end of the month. Literally. In the most recent case of Coffee County Alabama Office of the Constable, We spent three days writing a system for the deputy constables to issue electronic tickets. No paper. No filing cabinets. No lost documents. We wrote it for free and they use it for a $10 monthly subscription per login. The automatic generation of cases for the constables and the automatic generation of court dockets alone pay for the system, since they no longer have to pay someone to produce these reports. Even better, If you get pulled over in Coffee County, you probably are only going to be issued a warning, because they now have the ability to see if you are an habitual offender. You don't live there, so you get a warning.
That is the way we do things: Automation, make it easy. Doesn't everyone need some of that?
For example, Sentia had a contract with Jack Henry & Associates in Charlotte to help them add on some regulatory functionality to their Cruise application for Credit Unions. The regulation was called "Tila/Respa." I don't recall what that meant but it was a disclosure of loan terms to the borrower. the regulation was huge, about 50 entities and and average of 20 attributes per entity, or a little over a thousand database fields. My guy got there on September 1 last year and the functionality had to be implemented by October 1. Designing and building a database, designing and building a middle tier and designing and building a user interface using two guys for a thousand plus fields is getting close to impossible. My guy wrote a tool that took the specification, scraped out the names and datatypes of the attributes, assigned them to entities and generated a database. The other guy, meanwhile, was working on a tool to generate Windows forms (yes it was a Windows application, ewww) from the same specification. My guy then pointed Sentia's Object Relational Mapper (ORM) at the new database and generated the middle tier. After some trial and error with naming conventions and such, the generated front end was mated to the generated middle tier and while ugly, worked fine. This whole process took a week. Of course then then the specification changed (six more times) but because we chose to generate the application in toto, all we had to do was regenerate the application and make it pretty.
Why do I tell you this story? As problem solvers, those two guys really "thought outside the box" and delivered not what the client asked for, but what they needed and compensated for the changes they knew were coming. Instead of doing as they were told and "coding tila/respa" (whatever that means) they looked ahead to changed they knew would come (they always do) and instead of slaving away, they designed a flexible solution that would solve the real problem. It was still a lot of hard work, and harder work than "coding tila/respa" (again, whatever that means) but less of it, and flexible enough to compensate for the shifting sands of a requirements document left until the last possible second. So these same two guys knowing that Cruise itself was a complete train wreck with possibly a dozen ways to access its own database, procedural code that has been around since the VB4 days, and generally didn't work and couldn't be fixed, suggested that they use the same methods to cut out all the old middle tier code and replace it with the new code generated from the database schema.
What was the response? "That can't be done."
Well, yes it can and my guy just did it.
In fact, our sister company Sentia Health, just went through a complete rewrite of its EMR's entire user interface a few months ago. That is fairly comparable to what my guy suggested to Jack Henry. In another month or so, we are going regenerate the middle tier with an upgraded version from the new ORM that we have developed. that is PRECISELY what we suggested to Jack Henry and they said couldn't be done.
I still haven't given you the reason I made you read the Jack Henry Story. Here it is: Business doesn't want "outside the box" thinking. Further, they don't recognize it when they see it, or even when it is shoved down their throats and proven to work. There it is. THAT is the reason.
So yeah, we still haven't addressed buzzwords. The business guys don't get those either. XML, Web Services, XAML, Big Data, WPF, WCF, SOAP, REST, NoSQL, Hadoop, don't make sense in most applications and some don't make any sense at all. "The smart guys got a PhD for a dissertation on Big Data so I need some Big Data in my solution!" Well, no, you don't and there is no such thing as big data. Microsoft has a Big Data solution and it has been around for decades: SQL Server. Don't run procedural code against your unstructured data, structure it and run set based code using a database engine.
So once again, it is conclusion time. Until we quit letting the MBAs run anything, including their mouths, we are never going to get anywhere useful. Regular readers will recognize the Bob Cratchit theory: Businesses are doing nothing differently now than they did in 1843 at Scrooge and Marley's counting house, they just have the spreadsheets on a computer today.
The conclusion of the conclusion is to let the MBAs worry about funding and shares and corporate structure. Let the truly smart people decide HOW things are going to be done. THIS is what we have and THAT is what we want and we software guys will show you the best way to get from THIS to THAT. At Sentia we have automated entire businesses. Not just one, not two, but many. We took an existing business and automated it to the point that there is nothing to do but click the "Send bills" button at the end of the month. Literally. In the most recent case of Coffee County Alabama Office of the Constable, We spent three days writing a system for the deputy constables to issue electronic tickets. No paper. No filing cabinets. No lost documents. We wrote it for free and they use it for a $10 monthly subscription per login. The automatic generation of cases for the constables and the automatic generation of court dockets alone pay for the system, since they no longer have to pay someone to produce these reports. Even better, If you get pulled over in Coffee County, you probably are only going to be issued a warning, because they now have the ability to see if you are an habitual offender. You don't live there, so you get a warning.
That is the way we do things: Automation, make it easy. Doesn't everyone need some of that?
Tuesday, September 6, 2016
You Can't Automate Judgment and You Should Not Try
I have been corresponding recently with a couple of my code monkey buddies, both hard working, brilliant developers. They are complaining about the big applicant tracking packages employed by larger companies, that is, Oracle's Taleo, iCIMS, Bullhorn, et al.
They complain about several things:
Yes, there are some jobs that can't and shouldn't be automated. Stock trading. Engineering. Putting eyeballs on a resume. In the new age of information, We have people doing all kinds of menial tasks like opening and filling out spreadsheets and then emailing them around, that could and should be automated. Then we have some dumb piece of software actually making value judgments about something that even the person who came up with the requirements doesn't understand. Here is an example: My friend Randy is applying for a web developer job. One of the questions, after he retyped all his employment and education history that was in his resume of course, was "How much Web API experience do you have?" For those of you who don't know, Web API is nothing more than an MVC controller with HTTP methods like GET, POST and PUT. So instead of having a Create method in the Person Controller, you'd have a Post method with the exact same implementation. The only difference is the naming convention. Randy has built dozens of MVC applications, but has never even created a Web API application, because there is nothing to know. If he answers truthfully, he will certainly be passed over. If he give s a more correct answer, like 'all of it' he could been fired down the road for padding his resume.
This is indicative of the biggest problem in business today. The people running a company literally have no idea what the company does or how it does it and can't even recognize talent when it comes knocking. Years ago, the big buzzword was XML. Every job description you read REQUIRED the applicant to be able to read and write XML. Don't get me wrong, it's a great technology for inter-operation and essential to web services like SOAP. However in 20 some years of development, I've never had to read nor written XML. It's kind of like saying 'Do you have and can you explain your experience with breathing?'
'Yes, and no' in that order. Yes, I breathe, no, I am not going to give you a lecture in the chemistry of what happens in my lungs. You don't need to know.
Almost 30 years ago, I was helping my father frame a house. I stood up on the joists and he cut off and handed rafters up to me. Having been exposed to trigonometry, I was amazed that not only did Pop remember all the tables we had to memorize for trig, but that he was doing all the calculations for the rafter length in his head. I asked him how he did that. He said "you don't need to know."
I stewed on that for about 30 minutes and decided that I do need to know. I got a little belligerent and more forcefully posed the question again: "How do you know how long to cut off the rafters?"
He looked a little sheepish and replied "I don't know how long to cut off the rafters. It's built into the carpenter's square. Literally, you don't need to know." then he showed me how to cut off rafters with a carpenter's square.
What is the moral of the story? Sometimes, you just don't need to know. Randy doesn't need to know how long to cut rafters, he doesn't need to know how to breathe, he doesn't need to know XML and he doesn't need to know Web API. You just don't need to know.
In our post at SentiaHealth.com on September 2, 2016, Theory of Constraints: An Holistic Approach To Solutions Architecture: Why You All Are Doing It Wrong and What To Do Instead, we introduced Eli Goldratt and the Theory of Constraints and its application to the software industry. Mr. Goldratt states
Technology can bring benefits if and only if it diminishes a limitation. Long before the availability of technology we developed modes of behavior, policies, measurements and rules to help us accommodate that limitation. If we want to be successful with the implementation of new technology, we must find the things that helped us live with the old limitations and change the rules to take advantage of the new methods.
So what we need are smart people doing smart things, not Human Resources managers looking for buzzwords and weeding out people who don't have them. If you are going to successfully remove weeds, first you have to know what a weed looks like. Today we are picking on Human Resources but that department is just indicative of the larger problem. The problem is that literally nobody is taking advantage of the new technology to rid us of the limitations we have imposed to solve problems that we no longer have. You don't need spreadsheets anymore. Conversely, an in this example with Taleo et al, we have a limitation that technology cannot help with. You cannot (currently?) teach a computer to read a resume. You have to have human eyeballs and human judgement to figure out if someone is qualified for a technical job. That is it, No way around it. I say this, me, the guru or all things automation.
Even worse, Human Resources itself is attempting to do a job they aren't designed to do. They don't understand the technology, clearly, or they wouldn't be using software to automate an unautomatable job.
Yes, technology can help. Your "apply for this job application" should be a link to upload your resume. Process automated. You don't go to the hardware store and ask the clerk about the materials used to create your wrench or hammer or pliers. You don't know how to make those things so even if the clerk told you that this particular wrench was constructed from chrome plated, cold forged, 4140 chrome-molly billet, and he can't because he doesn't know either, you won't understand what that meant anyway.
Once more, if you can't do what I do, and you can't, don't presume to tell me how to do it. Go get a copy of Eli Goldratt's "Necessary But Not Sufficient." 80% of any business today can be automated. That means 80% fewer people, 80% fewer buildings, 80% electricity savings and 80% less cost. It also means you should be able to cut the price of your product or service by 80% and still make the same profit. I know this is true because I run MY business that way and I have automated 80% of the production of my products and I am 80% less expensive than any competition. Know what the 20% is that can't be automated, however. Get to know old Pareto. Let's remove the old limitations and free the spreadsheet emailers of the world to think and innovate and be a profit center, not a cost center. Let's think and innovate and NOT attempt to automate the unautomatable.
They complain about several things:
- duplicating information
- complicated password algorithms
- dumb questions with "N/A if no" answers
- half hour or more to apply for a job
Yes, there are some jobs that can't and shouldn't be automated. Stock trading. Engineering. Putting eyeballs on a resume. In the new age of information, We have people doing all kinds of menial tasks like opening and filling out spreadsheets and then emailing them around, that could and should be automated. Then we have some dumb piece of software actually making value judgments about something that even the person who came up with the requirements doesn't understand. Here is an example: My friend Randy is applying for a web developer job. One of the questions, after he retyped all his employment and education history that was in his resume of course, was "How much Web API experience do you have?" For those of you who don't know, Web API is nothing more than an MVC controller with HTTP methods like GET, POST and PUT. So instead of having a Create method in the Person Controller, you'd have a Post method with the exact same implementation. The only difference is the naming convention. Randy has built dozens of MVC applications, but has never even created a Web API application, because there is nothing to know. If he answers truthfully, he will certainly be passed over. If he give s a more correct answer, like 'all of it' he could been fired down the road for padding his resume.
This is indicative of the biggest problem in business today. The people running a company literally have no idea what the company does or how it does it and can't even recognize talent when it comes knocking. Years ago, the big buzzword was XML. Every job description you read REQUIRED the applicant to be able to read and write XML. Don't get me wrong, it's a great technology for inter-operation and essential to web services like SOAP. However in 20 some years of development, I've never had to read nor written XML. It's kind of like saying 'Do you have and can you explain your experience with breathing?'
'Yes, and no' in that order. Yes, I breathe, no, I am not going to give you a lecture in the chemistry of what happens in my lungs. You don't need to know.
Almost 30 years ago, I was helping my father frame a house. I stood up on the joists and he cut off and handed rafters up to me. Having been exposed to trigonometry, I was amazed that not only did Pop remember all the tables we had to memorize for trig, but that he was doing all the calculations for the rafter length in his head. I asked him how he did that. He said "you don't need to know."
I stewed on that for about 30 minutes and decided that I do need to know. I got a little belligerent and more forcefully posed the question again: "How do you know how long to cut off the rafters?"
He looked a little sheepish and replied "I don't know how long to cut off the rafters. It's built into the carpenter's square. Literally, you don't need to know." then he showed me how to cut off rafters with a carpenter's square.
What is the moral of the story? Sometimes, you just don't need to know. Randy doesn't need to know how long to cut rafters, he doesn't need to know how to breathe, he doesn't need to know XML and he doesn't need to know Web API. You just don't need to know.
In our post at SentiaHealth.com on September 2, 2016, Theory of Constraints: An Holistic Approach To Solutions Architecture: Why You All Are Doing It Wrong and What To Do Instead, we introduced Eli Goldratt and the Theory of Constraints and its application to the software industry. Mr. Goldratt states
Technology can bring benefits if and only if it diminishes a limitation. Long before the availability of technology we developed modes of behavior, policies, measurements and rules to help us accommodate that limitation. If we want to be successful with the implementation of new technology, we must find the things that helped us live with the old limitations and change the rules to take advantage of the new methods.
So what we need are smart people doing smart things, not Human Resources managers looking for buzzwords and weeding out people who don't have them. If you are going to successfully remove weeds, first you have to know what a weed looks like. Today we are picking on Human Resources but that department is just indicative of the larger problem. The problem is that literally nobody is taking advantage of the new technology to rid us of the limitations we have imposed to solve problems that we no longer have. You don't need spreadsheets anymore. Conversely, an in this example with Taleo et al, we have a limitation that technology cannot help with. You cannot (currently?) teach a computer to read a resume. You have to have human eyeballs and human judgement to figure out if someone is qualified for a technical job. That is it, No way around it. I say this, me, the guru or all things automation.
Even worse, Human Resources itself is attempting to do a job they aren't designed to do. They don't understand the technology, clearly, or they wouldn't be using software to automate an unautomatable job.
Yes, technology can help. Your "apply for this job application" should be a link to upload your resume. Process automated. You don't go to the hardware store and ask the clerk about the materials used to create your wrench or hammer or pliers. You don't know how to make those things so even if the clerk told you that this particular wrench was constructed from chrome plated, cold forged, 4140 chrome-molly billet, and he can't because he doesn't know either, you won't understand what that meant anyway.
Once more, if you can't do what I do, and you can't, don't presume to tell me how to do it. Go get a copy of Eli Goldratt's "Necessary But Not Sufficient." 80% of any business today can be automated. That means 80% fewer people, 80% fewer buildings, 80% electricity savings and 80% less cost. It also means you should be able to cut the price of your product or service by 80% and still make the same profit. I know this is true because I run MY business that way and I have automated 80% of the production of my products and I am 80% less expensive than any competition. Know what the 20% is that can't be automated, however. Get to know old Pareto. Let's remove the old limitations and free the spreadsheet emailers of the world to think and innovate and be a profit center, not a cost center. Let's think and innovate and NOT attempt to automate the unautomatable.
Subscribe to:
Posts (Atom)